From: | Zsolt Ero <zsolt(dot)ero(at)gmail(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, michael(at)paquier(dot)xyz, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Subject: | Re: could not link file in wal restore lines |
Date: | 2022-07-26 15:37:40 |
Message-ID: | CAKw-smDb9roHoW-h5MiMjYi1j5xWCXR1SdcnZTvc+YYx=aZ7CA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
It's this one: https://www.hetzner.com/dedicated-rootserver/ax51-nvme
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 26. Jul 2022 at 13:33:09, David Steele <david(at)pgmasters(dot)net> wrote:
> On 7/26/22 02:03, Kyotaro Horiguchi wrote:
>
> At Tue, 26 Jul 2022 11:48:14 +0900 (JST), Kyotaro Horiguchi <
> horikyota(dot)ntt(at)gmail(dot)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(at)pgmasters(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2022-07-26 15:48:23 | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands |
Previous Message | Tom Lane | 2022-07-26 15:37:14 | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands |