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
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++)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers