Typos in logical decoding
While reading the logical decoding code I noticed a few supposedly mistyped
comments, see the diff below.
Besides that, output_plugin_options argument of CreateInitDecodingContext
function is unused, and the function passes NIL to the corresponding argument
of StartupDecodingContext. This looks to me like a thinko.
--
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at
Attachments:
typos.patchtext/x-diffDownload
diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c
new file mode 100644
index 7c8a777..ecf9a03
*** a/src/backend/replication/logical/logical.c
--- b/src/backend/replication/logical/logical.c
*************** CreateInitDecodingContext(char *plugin,
*** 281,287 ****
LWLockRelease(ProcArrayLock);
/*
! * tell the snapshot builder to only assemble snapshot once reaching the a
* running_xact's record with the respective xmin.
*/
xmin_horizon = slot->data.catalog_xmin;
--- 281,287 ----
LWLockRelease(ProcArrayLock);
/*
! * tell the snapshot builder to only assemble snapshot once reaching the
* running_xact's record with the respective xmin.
*/
xmin_horizon = slot->data.catalog_xmin;
*************** LogicalIncreaseRestartDecodingForSlot(XL
*** 880,886 ****
}
/*
! * Handle a consumer's conformation having received all changes up to lsn.
*/
void
LogicalConfirmReceivedLocation(XLogRecPtr lsn)
--- 880,886 ----
}
/*
! * Handle a consumer's confirmation having received all changes up to lsn.
*/
void
LogicalConfirmReceivedLocation(XLogRecPtr lsn)
diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication/logical/reorderbuffer.c
new file mode 100644
index 00e31a2..9e2208a
*** a/src/backend/replication/logical/reorderbuffer.c
--- b/src/backend/replication/logical/reorderbuffer.c
*************** ReorderBufferGetTupleBuf(ReorderBuffer *
*** 466,473 ****
/*
* Most tuples are below MaxHeapTupleSize, so we use a slab allocator for
* those. Thus always allocate at least MaxHeapTupleSize. Note that tuples
! * tuples generated for oldtuples can be bigger, as they don't have
! * out-of-line toast columns.
*/
if (alloc_len < MaxHeapTupleSize)
alloc_len = MaxHeapTupleSize;
--- 466,473 ----
/*
* Most tuples are below MaxHeapTupleSize, so we use a slab allocator for
* those. Thus always allocate at least MaxHeapTupleSize. Note that tuples
! * generated for oldtuples can be bigger, as they don't have out-of-line
! * toast columns.
*/
if (alloc_len < MaxHeapTupleSize)
alloc_len = MaxHeapTupleSize;
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
new file mode 100644
index b4dc617..b5fa3db
*** a/src/backend/replication/logical/snapbuild.c
--- b/src/backend/replication/logical/snapbuild.c
*************** SnapBuildEndTxn(SnapBuild *builder, XLog
*** 901,907 ****
/*
* NB: This handles subtransactions correctly even if we started from
* suboverflowed xl_running_xacts because we only keep track of toplevel
! * transactions. Since the latter are always are allocated before their
* subxids and since they end at the same time it's sufficient to deal
* with them here.
*/
--- 901,907 ----
/*
* NB: This handles subtransactions correctly even if we started from
* suboverflowed xl_running_xacts because we only keep track of toplevel
! * transactions. Since the latter are always allocated before their
* subxids and since they end at the same time it's sufficient to deal
* with them here.
*/
*************** SnapBuildCommitTxn(SnapBuild *builder, X
*** 981,987 ****
* we reached consistency.
*/
forced_timetravel = true;
! elog(DEBUG1, "forced to assume catalog changes for xid %u because it was running to early", xid);
}
for (nxact = 0; nxact < nsubxacts; nxact++)
--- 981,987 ----
* we reached consistency.
*/
forced_timetravel = true;
! elog(DEBUG1, "forced to assume catalog changes for xid %u because it was running too early", xid);
}
for (nxact = 0; nxact < nsubxacts; nxact++)
On Mon, Jul 18, 2016 at 11:00 AM, Antonin Houska <ah@cybertec.at> wrote:
While reading the logical decoding code I noticed a few supposedly mistyped
comments, see the diff below.
Applied, thanks.
Besides that, output_plugin_options argument of CreateInitDecodingContext
function is unused, and the function passes NIL to the corresponding
argument
of StartupDecodingContext. This looks to me like a thinko.
I agree it looks like a thinko, and AFAICT all internal uses pass NIL there
anyway so it makes no difference on those. I'll wait for someone more
familiar with that code to comment though :)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/