Re: Logical Replication of sequences
| От | vignesh C |
|---|---|
| Тема | Re: Logical Replication of sequences |
| Дата | |
| Msg-id | CALDaNm1Fbu-HVHTm3ToGnJNXGVYsFvB0JvPZ0D+X4jWxyKFCZQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Logical Replication of sequences (vignesh C <vignesh21@gmail.com>) |
| Ответы |
Re: Logical Replication of sequences
Re: Logical Replication of sequences |
| Список | pgsql-hackers |
On Mon, 19 Jan 2026 at 14:54, vignesh C <vignesh21@gmail.com> wrote: > > On Wed, 24 Dec 2025 at 12:15, Shlok Kyal <shlok.kyal.oss@gmail.com> wrote: > > > > There is a buildfarm failure in fairywren at [1]. > The failure occurs when a sequence is dropped concurrently while > pg_get_sequence_data() is being executed as part of the copy_sequences > query. This can be reproduced by pausing execution inside > pg_get_sequence_data() and dropping the sequence in parallel. In such > a case, the function returns NULL values for last_value, which is not > currently expected by the subscriber side and results in a failure. > > I am analyzing this scenario further to identify a proper solution. I > will share the detailed analysis and proposed fix in a subsequent > email. pg_get_sequence_data() internally uses try_relation_open() rather than relation_open(). As a result, if the target sequence no longer exists at the time of access, the function does not raise an error and instead returns NULLs for the sequence state columns. The sequence sync worker code previously assumed these columns to be non NULL and asserted accordingly. This assumption does not hold in the presence of concurrent DDL. The patch updates the sequence sync logic to explicitly check for NULL values returned from pg_get_sequence_data(). If any of the required sequence state fields are NULL, the sequence sync worker skips processing that sequence to identify and report the missing sequences. The attached patch has the changes for the same. Regards, Vignesh
Вложения
В списке pgsql-hackers по дате отправления: