public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Thomas Munro <[email protected]>
Cc: Postgres hackers <[email protected]>
Subject: Re: Fail hard if xlogreader.c fails on out-of-memory
Date: Wed, 27 Sep 2023 08:14:15 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+hUKG+-YUfpnf3sT1GxNg6+smBf2NKWBFw-E+14T55U47aNew@mail.gmail.com>
References: <[email protected]>
<CA+hUKG+-YUfpnf3sT1GxNg6+smBf2NKWBFw-E+14T55U47aNew@mail.gmail.com>
On Wed, Sep 27, 2023 at 11:06:37AM +1300, Thomas Munro wrote:
> I don't have an opinion yet on your other thread about making this
> stuff configurable for replicas, but for the simple crash recovery
> case shown here, hard failure makes sense to me.
Also, if we conclude that we're OK with just failing hard all the time
for crash recovery and archive recovery on OOM, the other patch is not
really required. That would be disruptive for standbys in some cases,
still perhaps OK in the long-term. I am wondering if people have lost
data because of this problem on production systems, actually.. It
would not be possible to know that it happened until you see a page on
disk that has a somewhat valid LSN, still an LSN older than the
position currently being inserted, and that could show up in various
forms. Even that could get hidden quickly if WAL is written at a fast
pace after a crash recovery. A standby promotion at an LSN older
would be unlikely as monitoring solutions discard standbys lagging
behind N bytes.
> *A more detailed analysis would talk about sectors (page header is
> atomic), and consider whether we're only trying to defend ourselves
> against recycled pages written by PostgreSQL (yes), arbitrary random
> data (no, but it's probably still pretty good) or someone trying to
> trick us (no, and we don't stand a chance).
WAL would not be the only part of the system that would get borked if
arbitrary bytes can be inserted into what's read from disk, random or
not.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (2+ messages)
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]
Subject: Re: Fail hard if xlogreader.c fails on out-of-memory
In-Reply-To: <[email protected]>
* 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