0008-Edit-on-patch-0006-20230720.patch
text/x-patch
Filename: 0008-Edit-on-patch-0006-20230720.patch
Type: text/x-patch
Part: 1
Patch
Same data as JSON:
GET /api/v1/attachments/:id/patch
the parsed metadata as JSON — format, series position, per-file stats; never the diff bytes.
API reference →
Format: format-patch
Series: patch 0008
Subject: Edit on patch 0006
| File | + | − |
|---|---|---|
| src/backend/replication/logical/decode.c | 12 | 11 |
From 3da56bd0dd80a27e19b67d18648a4cd958883f65 Mon Sep 17 00:00:00 2001 From: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> 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