From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: base backup vs. concurrent truncation |
Date: | 2023-05-08 12:57:08 |
Message-ID: | CA+TgmoY6000W+=KXnRbis-DEad4gWDaDYHDJ6jDx48w+f7GRug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 1, 2023 at 12:54 PM Aleksander Alekseev
<aleksander(at)timescale(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Lakhin | 2023-05-08 13:00:01 | Re: benchmark results comparing versions 15.2 and 16 |
Previous Message | Robert Haas | 2023-05-08 12:46:48 | Re: [PATCH] Allow Postgres to pick an unused port to listen |