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.
