In the last day or so, both skink and mamba have hit this
in the pg_rewind test suite [1][2]:
#3 0x01f03f7c in ExceptionalCondition
(conditionName=conditionName@entry=0x2119c4c "pending_since == 0",
fileName=fileName@entry=0x2119454 "pgstat.c", lineNumber=lineNumber@entry=734)
at assert.c:66
#4 0x01d7994c in pgstat_report_stat (force=force@entry=true) at pgstat.c:734
#5 0x01d7a248 in pgstat_shutdown_hook (code=<optimized out>, arg=<optimized
out>) at pgstat.c:615
#6 0x01d1e7c0 in shmem_exit (code=code@entry=0) at ipc.c:243
#7 0x01d1e92c in proc_exit_prepare (code=code@entry=0) at ipc.c:198
#8 0x01d1e9fc in proc_exit (code=0) at ipc.c:111
#9 0x01cd5bd0 in ProcessRepliesIfAny () at walsender.c:2294
#10 0x01cd8084 in WalSndLoop (send_data=send_data@entry=0x1cd7628
<XLogSendPhysical>) at walsender.c:2790
#11 0x01cd8f40 in StartReplication (cmd=0xfd048210) at walsender.c:960
#12 exec_replication_command (cmd_string=cmd_string@entry=0xfd53c098
"START_REPLICATION 0/3000000 TIMELINE 2") at walsender.c:2135
#13 0x01d5bd84 in PostgresMain (dbname=<optimized out>, username=<optimized
out>) at postgres.c:4767
That assert appears to be several years old, and the
008_min_recovery_point.pl test script that's triggering it hasn't
changed very recently either, so I'm baffled where to start digging.
It has the odor of a timing problem, so maybe we just started hitting
this by chance. Still ... anybody have an idea?
regards, tom lane
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2025-04-13%2018%3A55%3A03
[2]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mamba&dt=2025-04-15%2001%3A00%3A04
