Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-29 Thread Bossart, Nathan
On 7/29/21, 12:59 AM, "Kyotaro Horiguchi" wrote: > At Thu, 29 Jul 2021 09:52:08 +0900, Michael Paquier > wrote in >> On Wed, Jul 28, 2021 at 08:28:12PM +, Bossart, Nathan wrote: >> > On 7/28/21, 11:32 AM, "Tom Lane" wrote: >> >> I follow the idea of using WaitLatch to ensure that the

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-29 Thread Kyotaro Horiguchi
At Thu, 29 Jul 2021 09:52:08 +0900, Michael Paquier wrote in > On Wed, Jul 28, 2021 at 08:28:12PM +, Bossart, Nathan wrote: > > On 7/28/21, 11:32 AM, "Tom Lane" wrote: > >> I follow the idea of using WaitLatch to ensure that the delays are > >> interruptible by postmaster signals, but even

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-28 Thread Michael Paquier
On Wed, Jul 28, 2021 at 08:28:12PM +, Bossart, Nathan wrote: > On 7/28/21, 11:32 AM, "Tom Lane" wrote: >> I follow the idea of using WaitLatch to ensure that the delays are >> interruptible by postmaster signals, but even that isn't worth a >> lot given the expected use of these things. I

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-28 Thread Bossart, Nathan
On 7/28/21, 11:32 AM, "Tom Lane" wrote: > I'm detecting a certain amount of lily-gilding here. Neither of these > delays are meant for anything except debugging purposes, and nobody as > far as I've heard has ever expressed great concern about identifying > which process they need to attach to

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-28 Thread Tom Lane
Justin Pryzby writes: > On Wed, Jul 28, 2021 at 09:10:35PM +0530, Bharath Rupireddy wrote: >> Hm. That's a good idea to show up in the ps display. > Keep in mind that ps is apparently so expensive under windows that the GUC > defaults to off. > The admin can leave the ps display off, but I

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-28 Thread Justin Pryzby
On Wed, Jul 28, 2021 at 09:10:35PM +0530, Bharath Rupireddy wrote: > On Wed, Jul 28, 2021 at 8:12 AM Kyotaro Horiguchi > wrote: > > > > - It seems that the additional wait-event is effectively useless for > > most of the processes. Considering that this feature is for debugging > > purpose,

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-28 Thread Bharath Rupireddy
On Wed, Jul 28, 2021 at 8:12 AM Kyotaro Horiguchi wrote: > > Hello. > > At Tue, 27 Jul 2021 11:04:09 +0530, Bharath Rupireddy > wrote in > > On Mon, Jul 26, 2021 at 11:03 PM Bossart, Nathan > > wrote: > > PSA v3 patch. > > I have some comments. > > - No harm, but it's pointless to feed

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-27 Thread Kyotaro Horiguchi
Hello. At Tue, 27 Jul 2021 11:04:09 +0530, Bharath Rupireddy wrote in > On Mon, Jul 26, 2021 at 11:03 PM Bossart, Nathan wrote: > PSA v3 patch. I have some comments. - No harm, but it's pointless to feed MyLatch to WaitLatch when WL_LATCH_SET is not set (or rather misleading). - It seems

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-27 Thread Bossart, Nathan
On 7/26/21, 10:34 PM, "Bharath Rupireddy" wrote: > PSA v3 patch. LGTM. The pre/post_auth_delay parameters seem to work as intended, and they are responsive to postmaster crashes. I didn't find any examples of calling WaitLatch() without WL_LATCH_SET, but the function appears to have support

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-26 Thread Bharath Rupireddy
On Mon, Jul 26, 2021 at 11:03 PM Bossart, Nathan wrote: > > For PreAuthDelay, with the comment I wanted to say that the MyLatch is > > not the correct one we would want to wait for. Since there is no > > problem in using it there, I changed the comment to following: > > /* > > *

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-26 Thread Bossart, Nathan
On 7/24/21, 9:16 AM, "Bharath Rupireddy" wrote: > On Fri, Jul 23, 2021 at 4:40 AM Bossart, Nathan wrote: >> I would suggest changing "attach from a debugger" to "attaching with a >> debugger." > > Thanks. IMO, the following looks better: > Waiting on connection startup before authentication

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-24 Thread Bharath Rupireddy
On Fri, Jul 23, 2021 at 4:40 AM Bossart, Nathan wrote: > I would suggest changing "attach from a debugger" to "attaching with a > debugger." Thanks. IMO, the following looks better: Waiting on connection startup before authentication to allow attaching a debugger to the process.

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-22 Thread Bossart, Nathan
On 7/12/21, 9:00 AM, "Bharath Rupireddy" wrote: > As suggested in [1], starting a new thread for discussing $subject > separately. {pre, post}_auth_delay waiting logic currently uses > pg_usleep which can't detect postmaster death. So, there are chances > that some of the backends still stay in

Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-15 Thread Bharath Rupireddy
On Mon, Jul 12, 2021 at 9:26 PM Bharath Rupireddy wrote: > > Hi, > > As suggested in [1], starting a new thread for discussing $subject > separately. {pre, post}_auth_delay waiting logic currently uses > pg_usleep which can't detect postmaster death. So, there are chances > that some of the

Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

2021-07-12 Thread Bharath Rupireddy
Hi, As suggested in [1], starting a new thread for discussing $subject separately. {pre, post}_auth_delay waiting logic currently uses pg_usleep which can't detect postmaster death. So, there are chances that some of the backends still stay in the system even when a postmaster crashes (for