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

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

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

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

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

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

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

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

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

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

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

Regards,
Manu