From 3da56bd0dd80a27e19b67d18648a4cd958883f65 Mon Sep 17 00:00:00 2001 From: Ashutosh Bapat Date: Thu, 20 Jul 2023 12:46:50 +0530 Subject: [PATCH 8/8] Edit on patch 0006 --- src/backend/replication/logical/decode.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/src/backend/replication/logical/decode.c b/src/backend/replication/logical/decode.c index e24ccd9af6..e219a29469 100644 --- a/src/backend/replication/logical/decode.c +++ b/src/backend/replication/logical/decode.c @@ -1441,19 +1441,20 @@ sequence_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf) /* * Handle sequence decode * - * Decoding sequences is a bit tricky, because while most sequence actions - * are non-transactional (not subject to rollback), some need to be handled - * as transactional. + * Decoding changes to sequences is a bit tricky, because while most sequence + * actions are non-transactional (not subject to rollback), some need to be + * handled as transactional. * - * By default, a sequence increment is non-transactional - we must not queue - * it in a transaction as other changes, because the transaction might get - * rolled back and we'd discard the increment. The downstream would not be - * notified about the increment, which is wrong. + * By default, a sequence change is non-transactional - we must not queue it in + * a transaction as other changes, because the transaction might get rolled back + * and we'd discard the increment. The downstream would not be notified about + * the increment, which is wrong. * - * On the other hand, the sequence may be created in a transaction. In this - * case we *should* queue the change as other changes in the transaction, - * because we don't want to send the increments for unknown sequence to the - * plugin - it might get confused about which sequence it's related to etc. + * On the other hand, the relfilenode associated with the sequence may be + * changed in a transaction. In this case we *should* queue the change as other + * changes in the transaction, because we don't want to send the sequence + * changes, which may be rolled back, to the plugin before the transaction is + * committed. */ void smgr_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf) -- 2.25.1