Re: non-exclusive backup cleanup is mildly broken

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: david(at)pgmasters(dot)net
Cc: magnus(at)hagander(dot)net, michael(at)paquier(dot)xyz, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: non-exclusive backup cleanup is mildly broken
Date: 2019-12-16 01:43:48
Message-ID: 20191216.104348.339446443166619592.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Fri, 13 Dec 2019 18:50:25 -0500, David Steele <david(at)pgmasters(dot)net> wrote in
> On 12/13/19 3:56 AM, Magnus Hagander wrote:
> > On Fri, Dec 13, 2019 at 9:00 AM Michael Paquier <michael(at)paquier(dot)xyz 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.
>
> +1. I think it is reasonable to expect pg_start/stop_backup() to be
> performed in its own session without prepared transactions.
>
> +more if this concession keeps other aspects of the code simpler.

However I don't object to the restriction, couldn't we allow the
cancel_before_shmem_exit to search for the given entry looping over
the before_shmem_exit array? If we don't do that, an assrtion is needed
instead.

Since pg_stop_backup_v2 is the only caller to the function in the
whole server code, making cancel_before_shmem_exit a bit wiser (and
slower) cannot hurt anyone.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2019-12-16 02:09:07 Re: recovery_min_apply_delay in archive recovery causes assertion failure in latch
Previous Message Thomas Munro 2019-12-16 00:26:10 Re: Collation versions on Windows (help wanted, apply within)