public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 16/18] doc review for logical decoding of prepared xacts 2+ messages / 2 participants [nested] [flat]
* [PATCH 16/18] doc review for logical decoding of prepared xacts @ 2021-01-24 03:03 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Justin Pryzby @ 2021-01-24 03:03 UTC (permalink / raw) 0aa8a01d04c8fe200b7a106878eebc3d0af9105c --- doc/src/sgml/logicaldecoding.sgml | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml index b854f2ccfc..71e9f36b8e 100644 --- a/doc/src/sgml/logicaldecoding.sgml +++ b/doc/src/sgml/logicaldecoding.sgml @@ -791,9 +791,9 @@ typedef void (*LogicalDecodeMessageCB) (struct LogicalDecodingContext *ctx, <para> The optional <function>filter_prepare_cb</function> callback is called to determine whether data that is part of the current - two-phase commit transaction should be considered for decode - at this prepare stage or as a regular one-phase transaction at - <command>COMMIT PREPARED</command> time later. To signal that + two-phase commit transaction should be considered for decoding + at this prepare stage or later as a regular one-phase transaction at + <command>COMMIT PREPARED</command> time. To signal that decoding should be skipped, return <literal>true</literal>; <literal>false</literal> otherwise. When the callback is not defined, <literal>false</literal> is assumed (i.e. nothing is @@ -820,11 +820,11 @@ typedef bool (*LogicalDecodeFilterPrepareCB) (struct LogicalDecodingContext *ctx The required <function>begin_prepare_cb</function> callback is called whenever the start of a prepared transaction has been decoded. The <parameter>gid</parameter> field, which is part of the - <parameter>txn</parameter> parameter can be used in this callback to - check if the plugin has already received this prepare in which case it + <parameter>txn</parameter> parameter, can be used in this callback to + check if the plugin has already received this PREPARE in which case it can skip the remaining changes of the transaction. This can only happen - if the user restarts the decoding after receiving the prepare for a - transaction but before receiving the commit prepared say because of some + if the user restarts the decoding after receiving the PREPARE for a + transaction but before receiving the COMMIT PREPARED, say because of some error. <programlisting> typedef void (*LogicalDecodeBeginPrepareCB) (struct LogicalDecodingContext *ctx, @@ -842,7 +842,7 @@ typedef bool (*LogicalDecodeFilterPrepareCB) (struct LogicalDecodingContext *ctx decoded. The <function>change_cb</function> callback for all modified rows will have been called before this, if there have been any modified rows. The <parameter>gid</parameter> field, which is part of the - <parameter>txn</parameter> parameter can be used in this callback. + <parameter>txn</parameter> parameter, can be used in this callback. <programlisting> typedef void (*LogicalDecodePrepareCB) (struct LogicalDecodingContext *ctx, ReorderBufferTXN *txn, @@ -856,9 +856,9 @@ typedef bool (*LogicalDecodeFilterPrepareCB) (struct LogicalDecodingContext *ctx <para> The required <function>commit_prepared_cb</function> callback is called - whenever a transaction commit prepared has been decoded. The + whenever a transaction COMMIT PREPARED has been decoded. The <parameter>gid</parameter> field, which is part of the - <parameter>txn</parameter> parameter can be used in this callback. + <parameter>txn</parameter> parameter, can be used in this callback. <programlisting> typedef void (*LogicalDecodeCommitPreparedCB) (struct LogicalDecodingContext *ctx, ReorderBufferTXN *txn, @@ -872,15 +872,15 @@ typedef bool (*LogicalDecodeFilterPrepareCB) (struct LogicalDecodingContext *ctx <para> The required <function>rollback_prepared_cb</function> callback is called - whenever a transaction rollback prepared has been decoded. The + whenever a transaction ROLLBACK PREPARED has been decoded. The <parameter>gid</parameter> field, which is part of the - <parameter>txn</parameter> parameter can be used in this callback. The + <parameter>txn</parameter> parameter, can be used in this callback. The parameters <parameter>prepare_end_lsn</parameter> and <parameter>prepare_time</parameter> can be used to check if the plugin - has received this prepare transaction in which case it can apply the + has received this PREPARE TRANSACTION in which case it can apply the rollback, otherwise, it can skip the rollback operation. The <parameter>gid</parameter> alone is not sufficient because the downstream - node can have prepared transaction with same identifier. + node can have a prepared transaction with same identifier. <programlisting> typedef void (*LogicalDecodeRollbackPreparedCB) (struct LogicalDecodingContext *ctx, ReorderBufferTXN *txn, @@ -1122,7 +1122,7 @@ OutputPluginWrite(ctx, true); the <function>stream_commit_cb</function> callback (or possibly aborted using the <function>stream_abort_cb</function> callback). If two-phase commits are supported, the transaction can be prepared using the - <function>stream_prepare_cb</function> callback, commit prepared using the + <function>stream_prepare_cb</function> callback, COMMIT PREPARED using the <function>commit_prepared_cb</function> callback or aborted using the <function>rollback_prepared_cb</function>. </para> -- 2.17.0 --lc9FT7cWel8HagAv Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0017-an-old-and-deleted-has-happened.patch" ^ permalink raw reply [nested|flat] 2+ messages in thread
* Typos in reorderbuffer.c. @ 2024-03-14 04:28 Kyotaro Horiguchi <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Kyotaro Horiguchi @ 2024-03-14 04:28 UTC (permalink / raw) To: pgsql-hackers Hello. While examining reorderbuffer.c, I found several typos. I'm not sure if fixing them is worthwhile, but I've attached a fix just in case. regards. -- Kyotaro Horiguchi NTT Open Source Software Center Attachments: [text/x-patch] fix_reorderbuffer_c_typos.patch (3.4K, ../../[email protected]/2-fix_reorderbuffer_c_typos.patch) download | inline diff: diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication/logical/reorderbuffer.c index 001f901ee6..92cf39ff74 100644 --- a/src/backend/replication/logical/reorderbuffer.c +++ b/src/backend/replication/logical/reorderbuffer.c @@ -32,7 +32,7 @@ * * In order to cope with large transactions - which can be several times as * big as the available memory - this module supports spooling the contents - * of a large transactions to disk. When the transaction is replayed the + * of large transactions to disk. When the transaction is replayed the * contents of individual (sub-)transactions will be read from disk in * chunks. * @@ -3078,10 +3078,10 @@ ReorderBufferImmediateInvalidation(ReorderBuffer *rb, uint32 ninvalidations, * least once for every xid in XLogRecord->xl_xid (other places in records * may, but do not have to be passed through here). * - * Reorderbuffer keeps some datastructures about transactions in LSN order, + * Reorderbuffer keeps some data structures about transactions in LSN order, * for efficiency. To do that it has to know about when transactions are seen * first in the WAL. As many types of records are not actually interesting for - * logical decoding, they do not necessarily pass though here. + * logical decoding, they do not necessarily pass through here. */ void ReorderBufferProcessXid(ReorderBuffer *rb, TransactionId xid, XLogRecPtr lsn) @@ -3513,11 +3513,11 @@ ReorderBufferLargestTXN(ReorderBuffer *rb) * snapshot because we don't decode such transactions. Also, we do not select * the transaction which doesn't have any streamable change. * - * Note that, we skip transactions that contains incomplete changes. There + * Note that, we skip transactions that contain incomplete changes. There * is a scope of optimization here such that we can select the largest * transaction which has incomplete changes. But that will make the code and * design quite complex and that might not be worth the benefit. If we plan to - * stream the transactions that contains incomplete changes then we need to + * stream the transactions that contain incomplete changes then we need to * find a way to partially stream/truncate the transaction changes in-memory * and build a mechanism to partially truncate the spilled files. * Additionally, whenever we partially stream the transaction we need to @@ -4701,8 +4701,8 @@ ReorderBufferToastAppendChunk(ReorderBuffer *rb, ReorderBufferTXN *txn, } /* - * Rejigger change->newtuple to point to in-memory toast tuples instead to - * on-disk toast tuples that may not longer exist (think DROP TABLE or VACUUM). + * Rejigger change->newtuple to point to in-memory toast tuples instead of + * on-disk toast tuples that may no longer exist (think DROP TABLE or VACUUM). * * We cannot replace unchanged toast tuples though, so those will still point * to on-disk toast data. @@ -4713,7 +4713,7 @@ ReorderBufferToastAppendChunk(ReorderBuffer *rb, ReorderBufferTXN *txn, * at unexpected times. * * We simply subtract size of the change before rejiggering the tuple, and - * then adding the new size. This makes it look like the change was removed + * then add the new size. This makes it look like the change was removed * and then added back, except it only tweaks the accounting info. * * In particular it can't trigger serialization, which would be pointless ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-03-14 04:28 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-01-24 03:03 [PATCH 16/18] doc review for logical decoding of prepared xacts Justin Pryzby <[email protected]> 2024-03-14 04:28 Typos in reorderbuffer.c. Kyotaro Horiguchi <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox