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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep
Дата
Msg-id 597521.1627497133@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Ответы Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep
Список pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> 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 wonder if it's of any concern
> that something so expensive can be caused by an unauthenticated connection.

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 for that purpose.  So I think it
is a *complete* waste of time to add any cycles to connection startup
to make these delays more visible.

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 don't see a need to
expend any extra effort on wait-reporting.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: speed up verifying UTF-8
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [PoC] Improve dead tuple storage for lazy vacuum