Re: base backup vs. concurrent truncation

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: base backup vs. concurrent truncation
Date: 2023-04-21 14:56:46
Message-ID: CAJ7c6TO1uY_wdx7cuKe6kTHGXWc3HdoRztjw2Ew9R-1R_5htjw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi again,

> 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.

Hm...

--
Best regards,
Aleksander Alekseev

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2023-04-21 15:03:07 Re: base backup vs. concurrent truncation
Previous Message Aleksander Alekseev 2023-04-21 14:50:34 Re: base backup vs. concurrent truncation