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
