Re: Fix publisher-side sequence permission reporting - Mailing list pgsql-hackers

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