Re: non-exclusive backup cleanup is mildly broken
От | Kyotaro Horiguchi |
---|---|
Тема | Re: non-exclusive backup cleanup is mildly broken |
Дата | |
Msg-id | 20191216.104348.339446443166619592.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: non-exclusive backup cleanup is mildly broken (David Steele <david@pgmasters.net>) |
Ответы |
Re: non-exclusive backup cleanup is mildly broken
|
Список | pgsql-hackers |
At Fri, 13 Dec 2019 18:50:25 -0500, David Steele <david@pgmasters.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@paquier.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
В списке pgsql-hackers по дате отправления: