Re: Logical Replication of sequences
| От | vignesh C |
|---|---|
| Тема | Re: Logical Replication of sequences |
| Дата | |
| Msg-id | CALDaNm2Sz+KEZE451d3JdyQmTrnVVFOiOHr6h-vf5J1+TpkbMQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Logical Replication of sequences (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: Logical Replication of sequences
|
| Список | pgsql-hackers |
On Tue, 20 Jan 2026 at 09:47, Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Mon, Jan 19, 2026 at 6:36 PM vignesh C <vignesh21@gmail.com> wrote: > > > > 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. > > > > - seqinfo_local->last_value = DatumGetInt64(slot_getattr(slot, ++col, &isnull)); > - Assert(!isnull); > + /* > + * If the sequence was dropped concurrently, pg_get_sequence_data() can > + * return NULLs. > + */ > + datum = slot_getattr(slot, ++col, &isnull); > + if (isnull) > + return COPYSEQ_SKIPPED; > + seqinfo_local->last_value = DatumGetInt64(datum); > > - seqinfo_local->is_called = DatumGetBool(slot_getattr(slot, ++col, &isnull)); > - Assert(!isnull); > + datum = slot_getattr(slot, ++col, &isnull); > + if (isnull) > + return COPYSEQ_SKIPPED; > + seqinfo_local->is_called = DatumGetBool(datum); > > Is there a case where the first one (last_value) is non-null but later > can be null? If not, then I think it is better to retain assert for > other cases. That is not possible. Updated accordingly with slight change to comment. The attached patch has the changes for the same. Regards, Vignesh
Вложения
В списке pgsql-hackers по дате отправления: