Horton

Re: Fix publisher-side sequence permission reporting

Fujii Masao <masao.fujii@gmail.com>

View thread View on postgr.es
From: Fujii Masao <masao.fujii@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Tristan Partin <tristan@partin.io>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-06-24T10:30:09Z
Lists: pgsql-hackers

Attachments

On Wed, Jun 24, 2026 at 5:50 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> On Wed, Jun 24, 2026 at 4:40 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > Assume a case where the primary fails and the system promotes standby
> > as a new primary. Then the subscriber starts sync from the new
> > primary, there it can lead to an unlogged sequence sync scenario?
>
> When I tested pg_get_sequence_data() with an unlogged sequence on
> new primary after promotion, I hit an assertion failure...

The assertion failure seems to be caused by seq_redo() not flushing
the init fork buffer from shared buffers. As a result, the init fork of
an unlogged sequence can remain invalid. During promotion,
ResetUnloggedRelations() creates the main fork by copying the init
fork from disk, so the main fork also becomes invalid. When
pg_get_sequence_data() later reads the invalid page, it hits the
assertion failure.

The attached patch adds a common function to flush an init fork buffer
and updates seq_redo() to use it. It also updates hash_xlog.c to
reuse the same function to simplify the code.

Thought?

Regards,

-- 
Fujii Masao

Commits

  1. Fix unlogged sequence corruption after standby promotion

  2. doc: Clarify pg_get_sequence_data() privileges and NULL results

  3. Fix misreporting of publisher sequence permissions during sync

  4. Introduce pg_sequence_read_tuple().