public inbox for [email protected]
help / color / mirror / Atom feedFrom: Robert Pang <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Nathan Bossart <[email protected]>
Cc: Kyotaro Horiguchi <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Back-patch of: avoid multiple hard links to same WAL file after a crash
Date: Tue, 17 Dec 2024 16:50:16 -0800
Message-ID: <CAJhEC04tBkYPF4q2uS_rCytauvNEVqdBAzasBEokfceFhF=KDQ@mail.gmail.com> (raw)
In-Reply-To: <YsORtfT4+fXj/[email protected]>
References: <CA+TgmobGi7b-5fjAWgEO0ebn516n0OyOi-j7+Hyz_j9sAG17og@mail.gmail.com>
<[email protected]>
<20220411165257.GB1915258@nathanxps13>
<[email protected]>
<20220412162742.GB2062175@nathanxps13>
<[email protected]>
<[email protected]>
<20220502173907.GB3351307@nathanxps13>
<20220502230613.GA3398932@nathanxps13>
<YnOwioN/[email protected]>
<YsORtfT4+fXj/[email protected]>
Dear team,
We recently observed a few cases where Postgres running on Linux
encountered an issue with WAL segment files. Specifically, two WAL
segments were linked to the same physical file after Postgres ran out
of memory and the OOM killer terminated one of its processes. This
resulted in the WAL segments overwriting each other and Postgres
failing a later recovery.
We found this fix [1] that has been applied to Postgres 16, but the
cases we observed were running Postgres 15. Given that older major
versions will be supported for a good number of years, and the
potential for irrecoverability exists (even if rare), we would like to
discuss the possibility of back-patching this fix.
Are there any technical reasons not to back-patch this fix to older
major versions?
Thank you for your consideration.
Sincerely,
Robert Pang
[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=dac1ff3
On Sat, May 7, 2022 at 1:19 AM Michael Paquier <[email protected]> wrote:
>
> On Thu, May 05, 2022 at 08:10:02PM +0900, Michael Paquier wrote:
> > I'd agree with removing all the callers at the end. pgrename() is
> > quite robust on Windows, but I'd keep the two checks in
> > writeTimeLineHistory(), as the logic around findNewestTimeLine() would
> > consider a past TLI history file as in-use even if we have a crash
> > just after the file got created in the same path by the same standby,
> > and the WAL segment init part. Your patch does that.
>
> As v16 is now open for business, I have revisited this change and
> applied 0001 to change all the callers (aka removal of the assertion
> for the WAL receiver when it overwrites a TLI history file). The
> commit log includes details about the reasoning of all the areas
> changed, for clarity, as of the WAL recycling part, the TLI history
> file part and basic_archive.
> --
> Michael
view thread (16+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Back-patch of: avoid multiple hard links to same WAL file after a crash
In-Reply-To: <CAJhEC04tBkYPF4q2uS_rCytauvNEVqdBAzasBEokfceFhF=KDQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox