Re: Can a child process detect postmaster death when in pg_usleep?
От
Michael Paquier
Тема
Re: Can a child process detect postmaster death when in pg_usleep?
Дата
Msg-id
YOJoYO8Ha9qCvv3N@paquier.xyz
Ответ на
Re: Can a child process detect postmaster death when in pg_usleep? (Bharath Rupireddy)
Список
Дерево обсуждения
Can a child process detect postmaster death when in pg_usleep? Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Can a child process detect postmaster death when in pg_usleep? Thomas Munro <thomas.munro@gmail.com>
Re: Can a child process detect postmaster death when in pg_usleep? Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Can a child process detect postmaster death when in pg_usleep? Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Can a child process detect postmaster death when in pg_usleep? Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Can a child process detect postmaster death when in pg_usleep? Aleksander Alekseev <aleksander@timescale.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? Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Can a child process detect postmaster death when in pg_usleep? Tom Lane <tgl@sss.pgh.pa.us>
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? Kyotaro Horiguchi <horikyota.ntt@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? Bharath Rupireddy <bharath.rupireddyforpostgres@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? Stephen Frost <sfrost@snowman.net>
Re: Can a child process detect postmaster death when in pg_usleep? Bharath Rupireddy <bharath.rupireddyforpostgres@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? Bharath Rupireddy <bharath.rupireddyforpostgres@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? Bharath Rupireddy <bharath.rupireddyforpostgres@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? Bharath Rupireddy <bharath.rupireddyforpostgres@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? Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
On Fri, Jul 02, 2021 at 12:03:07PM +0530, Bharath Rupireddy wrote: > 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. It seems to me that you should re-read the description of recoveryWakeupLatch at the top of xlog.c and check for which purpose it exists, which is, in this case, to wake up the startup process to accelerate WAL replay. So do_pg_stop_backup() has no business with it. Switching pg_stop_backup() to use a latch rather than pg_usleep() has benefits: - It simplifies the wait event handling. - The process waiting for the last WAL segment to be archived will be more responsive on signals like SIGHUP and on postmaster death. These don't sound bad to me to apply here, so 0002 could be simplified as attached. -- Michael
В списке pgsql-hackers по дате отправления
От: zhangjie2@fujitsu.com
Дата:
От: osumi.takamichi@fujitsu.com
Дата: