Re: Can a child process detect postmaster death when in pg_usleep?
От | Bharath Rupireddy |
---|---|
Тема | Re: Can a child process detect postmaster death when in pg_usleep? |
Дата | |
Msg-id | CALj2ACVikj-Hg32EjbOD70KuUWT4b9cptZSQK5WJRCasVdb9FA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Can a child process detect postmaster death when in pg_usleep? (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Can a child process detect postmaster death when in pg_usleep?
|
Список | pgsql-hackers |
On Fri, Jul 2, 2021 at 9:53 AM Michael Paquier <michael@paquier.xyz> wrote: > > On Mon, Jun 28, 2021 at 08:21:06PM +0530, Bharath Rupireddy wrote: > > The recoveryWakeupLatch and procLatch/MyLatch are being used for WAL > > replay and recovery conflict, respectively. Actually, I was earlier > > using procLatch/MyLatch, but came across the commit 00f690a23 which > > says that the two latches are reserved for specific purposes. I'm not > > quite sure which one to use when do_pg_stop_backup is called by the > > startup process. Any thoughts? > > Could you explain why you think dp_pg_stop_backup() can be called by > the startup process? AFAIK, this code path applies to two categories > of sessions: > - backend sessions, with the SQL functions calling this routine. > - WAL senders, aka anything that connects with replication=1 able to > use the BASE_BACKUP with the replication protocol. My bad. I was talking about the cases when do_pg_stop_backup is called while the server is in recovery mode i.e. backup_started_in_recovery = RecoveryInProgress(); evaluates to true. I'm not sure in these cases whether we should replace pg_usleep with WaitLatch. If yes, whether we should use procLatch/MyLatch or recoveryWakeupLatch as they are currently serving different purposes. Regards, Bharath Rupireddy.
В списке pgsql-hackers по дате отправления: