Re: Fix publisher-side sequence permission reporting

On Wed, 24 Jun 2026 at 16:00, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Wed, Jun 24, 2026 at 5:50 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> >
> > On Wed, Jun 24, 2026 at 4:40 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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?

Thanks for the patch. I verified that it fixes the issue with reading
unlogged sequences on a promoted standby.
Do you think it would be worthwhile to add a test for this scenario,
or do you feel the additional test is not necessary in this case?

Regards,
Vignesh