[PATCH] Fix stale relation close in sequence synchronization

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

Responses

Browse pgsql-hackers by date

  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