David, my server is a dedicated AMD Ryzen 7 3700X with 2 x 1 TB NVME SSD in RAID 0, so it's indeed quite fast, especially in I/O compared to most cloud hosting options with non-local storage.
I can imagine that trying the same stress test is not triggering race conditions on most cloud servers.
I'm happy to run tests as long as they are in Docker containers, I prefer not to install anything directly on the host.
Zsolt
On 7/26/22 02:03, Kyotaro Horiguchi wrote:
At Tue, 26 Jul 2022 11:48:14 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> Ah, sorry for posting following too-early messages in the thread.
>
> At Mon, 25 Jul 2022 08:40:12 -0400, David Steele <david@pgmasters.net> wrote in
>> Your system seems to be doing recovery pretty quickly. I wonder if
>> there is a race condition in WAL recycling?
And it has been fixed by cc2c7d65fc in PG15. That discussion [1]
concluded that we don't back-patch it.
[1] https://www.postgresql.org/message-id/flat/20210202151416.GB3304930%40rfd.leadboat.com
> Does anyone prefer some alternative? It's probably not worth
> back-patching anything for a restartpoint failure this rare, because
> most restartpoint outcomes are not user-visible.
I have responded on that thread to see if Noah can have a look and
decide if it would be worth back-patching cc2c7d65fc.
There have been other changes in this area (e.g. removing
durable_rename_excl) so it would be good to know if back-patching just
cc2c7d65fc will work.
Kyotaro, since you can reproduce the issue would you be willing to test
that?
Regards,
-David
