| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | 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-16 19:18:44 |
| Message-ID: | CA+TgmoaNbzJL9kZh_E_nsO_+GTbijFH23Dm-LQiggoeVQvycZQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2019-12-16 20:55:26 | Re: Clarifying/rationalizing Vars' varno/varattno/varnoold/varoattno |
| Previous Message | Pavel Stehule | 2019-12-16 19:11:48 | Re: polymorphic table functions light |