Re: Fix publisher-side sequence permission reporting

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Tristan Partin <tristan(at)partin(dot)io>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix publisher-side sequence permission reporting
Date: 2026-06-24 08:50:17
Message-ID: CAHGQGwH1Ssze3XM6wjoTjSLVOR041c6xP+vsdLP951=w8oG8bA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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...

---------------------
1. Create an unlogged sequence on the primary:

=# CREATE UNLOGGED SEQUENCE myseq;
CREATE SEQUENCE

2. Confirm that pg_get_sequence_data() returns NULL values on the standby:

=# SELECT * FROM pg_get_sequence_data('myseq');
last_value | is_called | page_lsn
------------+-----------+----------
(null) | (null) | (null)
(1 row)

3. Promote the standby, then call pg_get_sequence_data() on the new primary:

=# SELECT * FROM pg_get_sequence_data('myseq');

This results in the following assertion failure:

TRAP: failed Assert("((const PageHeaderData *) page)->pd_special >=
SizeOfPageHeaderData"), File:
"../../../src/include/storage/bufpage.h", Line: 357, PID: 96253
0 postgres 0x000000010d8d1412
ExceptionalCondition + 178
1 postgres 0x000000010d316970
PageValidateSpecialPointer + 128
2 postgres 0x000000010d3142df read_seq_tuple + 79
3 postgres 0x000000010d31635e
pg_get_sequence_data + 382
4 postgres 0x000000010d3bc42e
ExecMakeTableFunctionResult + 702
5 postgres 0x000000010d3da6cf FunctionNext + 175
6 postgres 0x000000010d3bde92 ExecScanFetch + 626
7 postgres 0x000000010d3bd88f ExecScanExtended + 95
8 postgres 0x000000010d3bd81f ExecScan + 95
9 postgres 0x000000010d3da2c5 ExecFunctionScan + 53
10 postgres 0x000000010d3b8a2b
ExecProcNodeFirst + 75
11 postgres 0x000000010d3affee ExecProcNode + 46
12 postgres 0x000000010d3ab507 ExecutePlan + 199
13 postgres 0x000000010d3ab3e0
standard_ExecutorRun + 368
14 postgres 0x000000010d3ab263 ExecutorRun + 67
15 postgres 0x000000010d6c2710 PortalRunSelect + 256
16 postgres 0x000000010d6c2170 PortalRun + 672
17 postgres 0x000000010d6bd53c
exec_simple_query + 1292
18 postgres 0x000000010d6bc6e5 PostgresMain + 2981
19 postgres 0x000000010d6b5228 BackendMain + 168
20 postgres 0x000000010d5a2269
postmaster_child_launch + 377
21 postgres 0x000000010d5a8775 BackendStartup + 277
22 postgres 0x000000010d5a6d85 ServerLoop + 341
23 postgres 0x000000010d5a5b84 PostmasterMain + 5748
24 postgres 0x000000010d43e533 main + 771
25 dyld 0x00007ff80fc71530 start + 3056
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-06-24 08:52:24 Re: [PATCH] Fix null pointer dereference in PG19
Previous Message Jakub Wartak 2026-06-24 08:48:19 Re: Problems with get_actual_variable_range's VISITED_PAGES_LIMIT