public inbox for [email protected]  

help / color / mirror / Atom feed

From: Chao Li <[email protected]>
To: Daniil Davydov <[email protected]>
Cc: Postgres hackers <[email protected]>
Subject: Re: Wrong comment for ReplicationSlotCreate
Date: Wed, 31 Dec 2025 10:32:17 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAJDiXghEf_BviOC9Ci-it2p1v0DOa+0yqfCyBV89rXSkcd-5JA@mail.gmail.com>
References: <CAJDiXggZXQZ7bD0QcTizDt6us9aX6ZKK4dWxzgb5x3+TsVHjqQ@mail.gmail.com>
	<[email protected]>
	<CAJDiXghEf_BviOC9Ci-it2p1v0DOa+0yqfCyBV89rXSkcd-5JA@mail.gmail.com>



> On Dec 30, 2025, at 18:07, Daniil Davydov <[email protected]> wrote:
> 
> Hi,
> 
> On Tue, Dec 30, 2025 at 4:18 PM Chao Li <[email protected]> wrote:
>> 
>> But I think the updated version is too simple. It loses the information that enabling two_phase later can result in missing PREPARE.
>> 
>> So, I would suggest something like:
>> ```
>> * two_phase: If enabled, allows decoding of prepared transactions.
>> *     Note that enabling this option after decoding has already advanced
>> *     may result in missing PREPARE records for transactions that were
>> *     prepared before the option was enabled.
>> 
>> ```
> 
> Thanks for the review!
> 
> As far as I understand, if the publisher prepares a transaction and
> then subscriber
> tries to create a subscription, walsender will wait until the prepared
> transaction is
> finished (during execution of  CREATE_REPLICATION_SLOT command).
> We can find this logic inside the SnapBuildFindSnapshot function. Thus, we
> cannot miss any PREPARE record for the created slot.
> 
> Am I missing something?
> 
> --
> Best regards,
> Daniil Davydov


You’re right that during CREATE_REPLICATION_SLOT, SnapBuildFindSnapshot() ensures we don’t miss PREPARE records for prepared transactions that exist at creation time.

1462aad2e introduced support for altering logical replication slot options, including two_phase, after the slot has been created. The commit comment says:
```
    Changing the 'two_phase' option for a subscription from 'true' to 'false'
    is permitted only when there are no pending prepared transactions
    corresponding to that subscription. Otherwise, the changes of already
    prepared transactions can be replicated again along with their corresponding
    commit leading to duplicate data or errors.
```

true->false is not allowed, however false->true is permitted. So, I think the old comment is still possible today:
```
*     Note that enabling this option after decoding has already advanced
*     may result in missing PREPARE records for transactions that were
*     prepared before the option was enabled.
```

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

view thread (6+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Wrong comment for ReplicationSlotCreate
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox