Re: Can a child process detect postmaster death when in pg_usleep? - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Can a child process detect postmaster death when in pg_usleep?
Date
Msg-id CALj2ACVikj-Hg32EjbOD70KuUWT4b9cptZSQK5WJRCasVdb9FA@mail.gmail.com
Whole thread Raw
In response to Re: Can a child process detect postmaster death when in pg_usleep?  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Can a child process detect postmaster death when in pg_usleep?  (Michael Paquier <michael@paquier.xyz>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: wrong relkind error messages
Next
From: Dilip Kumar
Date:
Subject: Re: Logical replication - schema change not invalidating the relation cache