Re: non-exclusive backup cleanup is mildly broken - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: non-exclusive backup cleanup is mildly broken
Date
Msg-id CABUevEzZcRc6SCBVDBBBt46OmUh3+P3w+aTKC6NSuB5rfHt-tw@mail.gmail.com
Whole thread Raw
In response to Re: non-exclusive backup cleanup is mildly broken  (Michael Paquier <michael@paquier.xyz>)
Responses Re: non-exclusive backup cleanup is mildly broken  (David Steele <david@pgmasters.net>)
List pgsql-hackers


On Fri, Dec 13, 2019 at 9:00 AM Michael Paquier <michael@paquier.xyz> wrote:
On Thu, Dec 12, 2019 at 01:52:31PM +0100, Magnus Hagander wrote:
> On Thu, Dec 12, 2019 at 5:58 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com>
> wrote:

> My first reaction would be to just disallow the combination of prepared
> transactions and start/stop backups. But looking at it it seems like an
> unnecessary restriction and an approach like this one seems better.

I think that's a bad idea to put a restriction of this kind.  There
are large consumers of 2PC, and everybody needs backups.

You misunderstood me. I certainly didn't mean that people who use 2PC shouldn't be able to use proper backups -- that would be *terrible*.

I meant disallowing pg_start_backup() in a session that had a prepared transaction, and disallowing preparing a transaction in a session with an ongoing backup. They would still work perfectly fine in *other* parallel sessions.

That said, being able to do it in the session itself is of course even better. 

--

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: non-exclusive backup cleanup is mildly broken
Next
From: Jean-Christophe Arnu
Date:
Subject: Re: PITR on DROP DATABASE, deleting of the database directory despitethe recovery_target_time set before.