Michael Paquier <mich...@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
