Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Update comments atop ReplicationSlotCreate.

  2. Fix typo in slot.c.

  3. Allow altering of two_phase option of a SUBSCRIPTION.

  1. Wrong comment for ReplicationSlotCreate

    Daniil Davydov <3danissimo@gmail.com> — 2025-12-29T13:39:36Z

    Hi,

I noticed that the comment for ReplicationSlotCreate function contains this
description for the "two_phase" option :

 * two_phase: Allows decoding of prepared transactions. We allow this option
 *     to be enabled only at the slot creation time. If we allow this option
 *     to be changed during decoding then it is quite possible that we skip
 *     prepare first time because this option was not enabled. Now next time
 *     during getting changes, if the two_phase option is enabled it can skip
 *     prepare because by that time start decoding point has been moved. So the
 *     user will only get commit prepared.

But commit [1] introduced the ability to alter the "two_phase" option for the
replication slot. Thus, I guess that the comment mentioned above is
outdated and we should change it.

[1] 1462aad2e4474ab61174f8ab00992cd3d6d57c7b

--
Best regards,
Daniil Davydov

  2. Re: Wrong comment for ReplicationSlotCreate

    Chao Li <li.evan.chao@gmail.com> — 2025-12-30T09:18:10Z

    
> On Dec 29, 2025, at 21:39, Daniil Davydov <3danissimo@gmail.com> wrote:
> 
> Hi,
> 
> I noticed that the comment for ReplicationSlotCreate function contains this
> description for the "two_phase" option :
> 
> * two_phase: Allows decoding of prepared transactions. We allow this option
> *     to be enabled only at the slot creation time. If we allow this option
> *     to be changed during decoding then it is quite possible that we skip
> *     prepare first time because this option was not enabled. Now next time
> *     during getting changes, if the two_phase option is enabled it can skip
> *     prepare because by that time start decoding point has been moved. So the
> *     user will only get commit prepared.
> 
> But commit [1] introduced the ability to alter the "two_phase" option for the
> replication slot. Thus, I guess that the comment mentioned above is
> outdated and we should change it.
> 
> [1] 1462aad2e4474ab61174f8ab00992cd3d6d57c7b
> 
> --
> Best regards,
> Daniil Davydov
> <0001-Fix-comment-for-ReplicationSlotCreate.patch>

The old comment claimed “We allow this option to be enabled only at the slot creation time” that is no longer true after commit 1462aad2e4474ab61174f8ab00992cd3d6d57c7b, so yes, the old comment need updating.

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.

```

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

  3. Re: Wrong comment for ReplicationSlotCreate

    Daniil Davydov <3danissimo@gmail.com> — 2025-12-30T10:07:22Z

    Hi,

On Tue, Dec 30, 2025 at 4:18 PM Chao Li <li.evan.chao@gmail.com> 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

  4. Re: Wrong comment for ReplicationSlotCreate

    Chao Li <li.evan.chao@gmail.com> — 2025-12-31T02:32:17Z

    
> On Dec 30, 2025, at 18:07, Daniil Davydov <3danissimo@gmail.com> wrote:
> 
> Hi,
> 
> On Tue, Dec 30, 2025 at 4:18 PM Chao Li <li.evan.chao@gmail.com> 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/