Re: Wrong comment for ReplicationSlotCreate
| От | Chao Li |
|---|---|
| Тема | Re: Wrong comment for ReplicationSlotCreate |
| Дата | |
| Msg-id | A474F4A5-EE98-40D9-95F7-543BE81EEB1C@gmail.com обсуждение исходный текст |
| Ответ на | Re: Wrong comment for ReplicationSlotCreate (Daniil Davydov <3danissimo@gmail.com>) |
| Список | pgsql-hackers |
> On Jan 2, 2026, at 00:31, Daniil Davydov <3danissimo@gmail.com> wrote: > > Hi, > > On Wed, Dec 31, 2025 at 9:32 AM Chao Li <li.evan.chao@gmail.com> wrote: >> >> You’re right that during CREATE_REPLICATION_SLOT, SnapBuildFindSnapshot() ensures we don’t miss PREPARE records for preparedtransactions that exist at creation time. >> >> 1462aad2e introduced support for altering logical replication slot options, including two_phase, after the slot has beencreated. 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. >> ``` >> > > Hm, I still can't understand why the comment that you provided is correct. > > How can we "miss PREPARE records" if slot creation requires all prepared > transactions to finish? The commit message says about risks during the > change of the parameter "on the fly". But we are dealing with slot creation. > > -- > Best regards, > Daniil Davydov No problem, maybe I am wrong. Then please ignore my comment and wait for other review comments. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
В списке pgsql-hackers по дате отправления: