| From: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Subject: | [PATCH] Fix stale relation close in sequence synchronization |
| Date: | 2026-04-28 11:24:24 |
| Message-ID: | CAJTYsWWOuw-yfmzotV4jCJ6LLxEsb=STLcGtDYXOxRcU9Te3Pw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
I found a crash in the logical replication sequence synchronization worker
when the publisher returns NULL sequence data for a sequence after at least
one sequence in the same sync batch has already been processed.
One way to reproduce this is to use a subscription that connects to the
publisher as a replication role that can read one published sequence but
cannot read another one. pg_get_sequence_data() returns NULLs for the
inaccessible sequence. In get_and_validate_seq_info(), that path returns
COPYSEQ_SKIPPED before assigning a new value to the Relation output
argument.
copy_sequences() then still sees the Relation pointer left from the previous
row and calls table_close() on it again. On a cassert build, this trips:
TRAP: failed Assert("rel->rd_refcnt > 0"); "relcache.c" file
The attached patch clears the output Relation pointer at the start of
get_and_validate_seq_info() and clears the local pointer in copy_sequences()
after closing it. That keeps early returns from reusing a relation from a
previous row.
The patch also adds a TAP test to 036_sequences.pl.
Thoughts?
Regards,
Ayush
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Fix-stale-relation-close-in-sequence-synchronization.patch | application/octet-stream | 4.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2026-04-28 11:28:49 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Ajin Cherian | 2026-04-28 11:19:38 | [PATCH] Preserve replication origin OIDs in pg_upgrade |