Re: non-exclusive backup cleanup is mildly broken

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: non-exclusive backup cleanup is mildly broken
Date: 2019-12-17 02:46:03
Message-ID: CAHGQGwGO2JMxZoyu9axk7pV7UwB8Tsxnr7t2O_+j31OH0MJXJQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 17, 2019 at 4:19 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Sun, Dec 15, 2019 at 8:44 PM Kyotaro Horiguchi
> <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > 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.
>
> That's actually not true. It's called from
> PG_END_ENSURE_ERROR_CLEANUP. Still, it wouldn't cost a lot to fix this
> that way. However, I think that it's better to fix it the other way,
> as I mentioned in my original email.

+1

Not only PREPARE but also other commands that we may add in the future
can cause the same issue, so it's better to address the root cause rather
than working around by disallowing PREPARE.

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2019-12-17 03:03:13 Re: Fastpath while arranging the changes in LSN order in logical decoding
Previous Message Andres Freund 2019-12-17 02:26:48 Re: reducing memory usage by using "proxy" memory contexts?