Re: BUG #19764: ManualBug3 Assert failure in pgstat_setup_shared_refs crashes initdb

Sorry for the two-day delay in responding, and thank you for the detailed investigation.

I agree with your conclusion. The assertion failure was caused by my incremental build without dependency tracking, which left some `pgstat_*.o` files compiled against the old `PgStat_ShmemControl` layout. It was therefore a build artifact caused by stale object files, not a bug in PostgreSQL 19rc1 or master.

The line-number mismatch also confirms that the backtrace I reported did not come from the claimed REL_19_RC1 tree. I should have verified the exact source tree and reproduced the issue with a clean build before reporting it.

I apologize for the confusion and for the time spent investigating this. Please consider my original report withdrawn.

violin
1217816127(at)qq(dot)com

Original


From: Manu <manuelreyesbravo(at)gmail(dot)com&gt;
Date: 2026-10-17 15:05
To: pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org&gt;, Michael Paquier <michael(at)paquier(dot)xyz&gt;, Tomas Vondra <tomas(at)vondra(dot)me&gt;
Cc: 1217816127 <1217816127(at)qq(dot)com&gt;, PG Bug reporting form <noreply(at)postgresql(dot)org&gt;
Subject: Re: BUG #19764: ManualBug3 Assert failure in pgstat_setup_shared_refs crashes initdb

On&nbsp;Fri,&nbsp;Oct&nbsp;16,&nbsp;2026&nbsp;at&nbsp;1:00&nbsp;PM&nbsp;Michael&nbsp;Paquier&nbsp;wrote:
&gt;&nbsp;These&nbsp;code&nbsp;paths&nbsp;run&nbsp;under&nbsp;initdb&nbsp;in&nbsp;the&nbsp;buildfarm&nbsp;and&nbsp;the&nbsp;CI&nbsp;on&nbsp;a
&gt;&nbsp;daily&nbsp;basis&nbsp;hundreds&nbsp;of&nbsp;times&nbsp;or&nbsp;even&nbsp;more&nbsp;than&nbsp;that.&nbsp;&nbsp;Of&nbsp;course
&gt;&nbsp;there&nbsp;could&nbsp;be&nbsp;a&nbsp;bug,&nbsp;but&nbsp;I&nbsp;just&nbsp;suspect&nbsp;a&nbsp;false&nbsp;positive.

I&nbsp;ran&nbsp;controlled&nbsp;builds&nbsp;to&nbsp;settle&nbsp;the&nbsp;clean&nbsp;vs&nbsp;incremental&nbsp;build&nbsp;question.

Clean&nbsp;builds&nbsp;(git&nbsp;clean&nbsp;-fdx;&nbsp;./configure&nbsp;--enable-cassert&nbsp;--enable-debug
--enable-depend;&nbsp;make;&nbsp;make&nbsp;install),&nbsp;initdb&nbsp;run&nbsp;50&nbsp;times&nbsp;serially&nbsp;and&nbsp;50&nbsp;times
8-way&nbsp;parallel&nbsp;on&nbsp;each:

&nbsp;&nbsp;REL_19_RC1&nbsp;(0b8bff042a),&nbsp;REL_19_STABLE&nbsp;(58d16be8ac),&nbsp;master&nbsp;(23e7ca78a0)
&nbsp;&nbsp;and&nbsp;44539786b8:&nbsp;400/400&nbsp;OK,&nbsp;no&nbsp;assertion&nbsp;failure.

Incremental&nbsp;build&nbsp;as&nbsp;Tomas&nbsp;described&nbsp;(build&nbsp;at&nbsp;44539786b8^,&nbsp;check&nbsp;out
44539786b8,&nbsp;make&nbsp;again,&nbsp;configured&nbsp;without&nbsp;--enable-depend):&nbsp;initdb&nbsp;fails
10/10&nbsp;with

&nbsp;&nbsp;TRAP:&nbsp;failed&nbsp;Assert("pgStatSharedRefAge&nbsp;!=&nbsp;0"),&nbsp;File:&nbsp;"pgstat_shmem.c",&nbsp;Line:&nbsp;505

The&nbsp;same&nbsp;incremental&nbsp;update&nbsp;with&nbsp;--enable-depend:&nbsp;100/100&nbsp;OK.

What&nbsp;goes&nbsp;wrong:&nbsp;44539786b8&nbsp;adds&nbsp;kind_hash_handles[]&nbsp;and&nbsp;raw_kind_dsa_area[]
to&nbsp;PgStat_ShmemControl&nbsp;ahead&nbsp;of&nbsp;is_shutdown,&nbsp;which&nbsp;moves&nbsp;gc_request_count&nbsp;from
offset&nbsp;24&nbsp;to&nbsp;552.&nbsp;Without&nbsp;dependency&nbsp;tracking,&nbsp;only&nbsp;pgstat.o&nbsp;and&nbsp;pgstat_shmem.o
get&nbsp;rebuilt;&nbsp;the&nbsp;other&nbsp;pgstat_*.o&nbsp;keep&nbsp;the&nbsp;old&nbsp;layout.&nbsp;The&nbsp;stale
pgstat_archiver_reset_all_cb()&nbsp;still&nbsp;addresses&nbsp;archiver&nbsp;at&nbsp;shmem+288,&nbsp;so&nbsp;its
reset_offset&nbsp;covers&nbsp;448..584,&nbsp;which&nbsp;now&nbsp;includes&nbsp;gc_request_count.&nbsp;When&nbsp;there
is&nbsp;no&nbsp;stats&nbsp;file,&nbsp;pgstat_restore_stats()&nbsp;-&gt;&nbsp;pgstat_reset_after_failure()&nbsp;calls
that&nbsp;callback,&nbsp;it&nbsp;copies&nbsp;the&nbsp;(zero)&nbsp;stats&nbsp;over&nbsp;reset_offset,&nbsp;and
gc_request_count&nbsp;drops&nbsp;from&nbsp;1&nbsp;to&nbsp;0.&nbsp;That&nbsp;is&nbsp;the&nbsp;sequence&nbsp;in&nbsp;the&nbsp;report;&nbsp;with&nbsp;gdb
I&nbsp;see&nbsp;gc_request_count&nbsp;=&nbsp;1&nbsp;on&nbsp;entry&nbsp;to&nbsp;pgstat_archiver_reset_all_cb&nbsp;and&nbsp;0&nbsp;in&nbsp;the
next&nbsp;pgstat_setup_shared_refs().&nbsp;With&nbsp;a&nbsp;clean&nbsp;build&nbsp;the&nbsp;same&nbsp;callback&nbsp;runs&nbsp;and
the&nbsp;counter&nbsp;stays&nbsp;at&nbsp;1.

Leaving&nbsp;only&nbsp;pgstat_archiver.o&nbsp;stale&nbsp;reproduces&nbsp;it&nbsp;20/20.&nbsp;Rebuilding&nbsp;only
pgstat_archiver.o&nbsp;makes&nbsp;this&nbsp;assertion&nbsp;go&nbsp;away,&nbsp;but&nbsp;then&nbsp;the&nbsp;other&nbsp;stale&nbsp;objects
corrupt&nbsp;other&nbsp;parts&nbsp;of&nbsp;shared&nbsp;memory&nbsp;(Assert("list-&gt;head&nbsp;!=&nbsp;procno")&nbsp;in
proclist.h),&nbsp;so&nbsp;a&nbsp;tree&nbsp;in&nbsp;that&nbsp;state&nbsp;isn't&nbsp;usable&nbsp;at&nbsp;all.

So&nbsp;I&nbsp;agree&nbsp;with&nbsp;Tomas&nbsp;and&nbsp;Michael:&nbsp;this&nbsp;is&nbsp;a&nbsp;build&nbsp;artifact,&nbsp;not&nbsp;a&nbsp;bug&nbsp;in&nbsp;19rc1
or&nbsp;master.&nbsp;44539786b8&nbsp;is&nbsp;only&nbsp;on&nbsp;master,&nbsp;and&nbsp;in&nbsp;19rc1&nbsp;this&nbsp;assertion&nbsp;is&nbsp;at
pgstat_shmem.c:391,&nbsp;so&nbsp;the&nbsp;trace&nbsp;in&nbsp;the&nbsp;report&nbsp;seems&nbsp;to&nbsp;come&nbsp;from&nbsp;a&nbsp;different
tree&nbsp;than&nbsp;19rc1.

Regards,
Manu