On Wed, 24 Jun 2026 at 16:00, Fujii Masao <[email protected]> wrote: > > On Wed, Jun 24, 2026 at 5:50 PM Fujii Masao <[email protected]> wrote: > > > > On Wed, Jun 24, 2026 at 4:40 PM Amit Kapila <[email protected]> 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
