Michael Paquier <michael@paquier.xyz> writes:
> I have been working on that over the last couple of days, and applied
> a fix down to 10. One thing that I did not like in the test was the
> use of compare() to check if the contents of the WAL segment before
> and after the timeline jump remained the same as this would have been
> unstable with any concurrent activity. Instead, I have added a phase
> at the end of the test with an extra checkpoint and recovery triggered
> once, which is enough to reproduce the PANIC reported at the top of
> the thread.
Buildfarm member hornet just reported a failure in this test:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2021-06-27%2013%3A40%3A57
the critical bit being
2021-06-27 17:35:46.504 UTC [11862234:1] [unknown] LOG: connection received: host=[local]
2021-06-27 17:35:46.505 UTC [18350260:12] LOG: recovering prepared transaction 734 from shared memory
TRAP: FailedAssertion("TransactionIdPrecedesOrEquals(TransactionXmin, RecentXmin)", File: "procarray.c", Line: 2492,
PID:11862234)
2021-06-27 17:35:46.511 UTC [14876838:4] LOG: database system is ready to accept connections
It's not clear whether this is a problem with the test case or an
actual server bug, but I'm leaning to the latter theory. My gut
feel is it's some problem in the "snapshot scalability" work. It
doesn't look the same as the known open issue, but maybe related?
regards, tom lane
