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 | CALj2ACXq284XyZTOP_v63Wjg3GM1+N0_rtpgJkvmPxgRJK7JaA@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?
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Can a child process detect postmaster death when in pg_usleep? (Michael Paquier <michael@paquier.xyz>) |
Список | pgsql-hackers |
On Thu, Jun 24, 2021 at 12:04 PM Michael Paquier <michael@paquier.xyz> wrote: > > On Tue, Apr 20, 2021 at 07:36:39AM +0530, Bharath Rupireddy wrote: > > I'm attaching 3 patches that replace pg_usleep with WaitLatch: 0001 in > > lazy_truncate_heap, 0002 in do_pg_stop_backup and 0003 for Pre and > > Post Auth Delay. Regression tests pass with these patches. Please > > review them. > > + if (backup_started_in_recovery) > + latch = &XLogCtl->recoveryWakeupLatch; > + else > + latch = MyLatch; > recoveryWakeupLatch is used by the startup process, but it has nothing > to do with do_pg_stop_backup(). Why are you doing that? 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? > I can get behind the change for the truncation lock when finishing a > VACUUM as that helps with monitoring. Thanks. Please let me know if there are any comments on v1-0001-Use-a-WaitLatch-for-lock-waiting-in-lazy_truncate.patch. > Now, I am not sure I get the > point of changing anything for {post,pre}_auth_delay that are > developer options. Please note that at this stage we don't know the > backend activity in pg_stat_activity, so the use of wait events is not > really interesting. Hm. I was earlier thinking from the perspective that the processes should be able to detect the postmaster death if the {post,pre}_auth_delay are set to higher values. Now, I agree that the auth delays are happening at the initial stages of the processes and if the developers(not common users) set the higher values for the GUCs, let them deal with the problem of the processes not detecting the postmaster death. > On top of that, not reacting on signals can be > interesting to keep as a behavior for developers? Yeah, it can be useful at times as it enables debugging even when the postmaster dies. With Regards, Bharath Rupireddy.
В списке pgsql-hackers по дате отправления: