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> |
Subject: | Re: base backup vs. concurrent truncation |
Date: | 2023-04-21 15:03:07 |
Message-ID: | CA+TgmobOcRWES8d4WLZ+PzCuaSuqZD+nHstL3uZcpWx2g8u+xg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 21, 2023 at 10:56 AM Aleksander Alekseev
<aleksander(at)timescale(dot)com> wrote:
> > Assuming this is the case perhaps we can reduce the scenario and
> > consider this simpler one:
> >
> > 1. The table is truncated
> > 2. The DBMS is killed before making a checkpoint
> > 3. We are in recovery and presumably see a pair of 0.5 Gb segments
> >
> > Or can't we?
>
> Oh, I see. If the process will be killed this perhaps is not going to
> happen. Whether this can happen if we pull the plug from the machine
> is probably a design implementation of the particular filesystem and
> whether it's journaled.
Right. I mentioned that scenario in the original email:
"Furthermore, I think that the problem could arise without performing a
backup at all: say that the server crashes on the OS level in
mid-truncation, and the truncation of segment 0 reaches disk but the
removal of segment 1 does not."
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Regina Obe | 2023-04-21 15:27:19 | Order changes in PG16 since ICU introduction |
Previous Message | Aleksander Alekseev | 2023-04-21 14:56:46 | Re: base backup vs. concurrent truncation |