Re: base backup vs. concurrent truncation - Mailing list pgsql-hackers

From Robert Haas
Subject Re: base backup vs. concurrent truncation
Date
Msg-id CA+TgmoY6000W+=KXnRbis-DEad4gWDaDYHDJ6jDx48w+f7GRug@mail.gmail.com
Whole thread Raw
In response to Re: base backup vs. concurrent truncation  (Aleksander Alekseev <aleksander@timescale.com>)
Responses Re: base backup vs. concurrent truncation
Re: base backup vs. concurrent truncation
List pgsql-hackers
On Mon, May 1, 2023 at 12:54 PM Aleksander Alekseev
<aleksander@timescale.com> wrote:
> So I'm still unable to reproduce the described scenario, at least on PG16.

Well, that proves that either (1) the scenario that I described is
impossible for some unknown reason or (2) something is wrong with your
test scenario. I bet it's (2), but if it's (1), it would be nice to
know what the reason is. One can't feel good about code that appears
on the surface to be broken even if one knows that some unknown
magical thing is preventing disaster.

I find it pretty hard to accept that there's no problem at all here,
especially in view of the fact that Andres independently posted about
the same issue on another thread. It's pretty clear from looking at
the code that mdnblocks() can't open any segments past the first one
that isn't of the maximum possible size. It's also fairly clear that a
crash or a base backup can create such situations. And finally it's
pretty clear that having an old partial segment be rediscovered due to
the relation be re-extended would be quite bad. So how can there not
be a problem? I admit I haven't done the legwork to nail down a test
case where everything comes together just right to show user-visible
breakage, but your success in finding one where it doesn't is no proof
of anything.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Allow Postgres to pick an unused port to listen
Next
From: Alexander Lakhin
Date:
Subject: Re: benchmark results comparing versions 15.2 and 16