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

From Andres Freund
Subject Re: base backup vs. concurrent truncation
Date
Msg-id 20230425172858.ji4jhzv7fdzbhubf@awork3.anarazel.de
Whole thread Raw
In response to Re: base backup vs. concurrent truncation  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: base backup vs. concurrent truncation  (Aleksander Alekseev <aleksander@timescale.com>)
Re: base backup vs. concurrent truncation  (Andres Freund <andres@anarazel.de>)
Re: base backup vs. concurrent truncation  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Hi,

On 2023-04-25 11:42:43 -0400, Robert Haas wrote:
> On Mon, Apr 24, 2023 at 8:03 PM Andres Freund <andres@anarazel.de> wrote:
> > What we've discussed somewhere in the past is to always truncate N+1 when
> > creating the first page in N. I.e. if we extend into 23456.1, we truncate
> > 23456.2 to 0 blocks.  As far as I can tell, that'd solve this issue?
> 
> Yeah, although leaving 23456.2 forever unless and until that happens
> doesn't sound amazing.

It isn't - but the alternatives aren't great either. It's not that easy to hit
this scenario, so I think something along these lines is more palatable than
adding a pass through the entire data directory.

I think eventually we'll have to make the WAL logging bulletproof enough
against this to avoid the risk of it. I think that is possible.

I suspect we would need to prevent checkpoints from happening in the wrong
moment, if we were to go down that route.

I guess that eventually we'll need to polish the infrastructure for
determining restartpointsm so that delayChkptFlags doesn't actually prevent
checkpoints, just moves the restart to a safe LSN.  Although I guess that
truncations aren't frequent enough (compared to transaction commits), for that
to be required "now".

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Issue in postgres_fdw causing unnecessary wait for cancel request reply
Next
From: Melanie Plageman
Date:
Subject: Re: pg_stat_io for the startup process