Re: Failing assertion while taking a restartpoint during crash recovery

On Sun, Aug 16, 2026 at 10:21 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> I am not concerned with the addition of this new flag. You are
> outsourcing a check based on ArchiveRecoveryRequested *and*
> EnableHotStandby to rely on a single state once we have called
> StartupSUBTRANS(), so you are simplifying the recovery logic. This
> argument counts as a +1 here.

Thanks for the review!

> Fujii-san, how did you reproduce the problem? Just by reusing the
> script?

TBH, I didn't see the attached script. Based on Imran's explanation,
I came up with the following procedure to reproduce the issue.

------------------------------------------
initdb -D data
cat <<EOF >> data/postgresql.conf
checkpoint_timeout = 30s
wal_keep_size = 100GB
full_page_writes = off
EOF
pg_ctl -D data start
pg_basebackup -D test -c fast

psql -c "CREATE TABLE t (i uuid primary key, j uuid unique)"
for tmp in $(seq 1 4); do
psql -c "INSERT INTO t SELECT uuidv7(), uuidv4() FROM
generate_series(1, 5000000)" &
done

(*) At this point, I usually wait until a sufficient amount of WAL
has been generated, rather than waiting for all four INSERTs to
complete, since they take quite a while.

pg_ctl -D data -m i stop
mv data/pg_wal/0000000100000000000000* test/pg_wal/
pg_ctl -D test start
------------------------------------------

> If we've failed detected this defect for so many years,
> perhaps this warrants a test? If it proves to be expensive in terms
> of cycles, I'd be a bit meh.

The test would need to trigger a restartpoint during crash recovery,
which I'm afraid could be expensive.

> One question that has not been raised is if exposing this new flag has
> any value for pg_stat_recovery.

I'm not sure how useful it would be to expose this flag to end users...

Regards,

--
Fujii Masao