Re: On login trigger: take three

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: On login trigger: take three
Дата
Msg-id 2133270.1698592561@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: On login trigger: take three  (Mikhail Gribkov <youzhick@gmail.com>)
Ответы Re: On login trigger: take three  (Alexander Korotkov <aekorotkov@gmail.com>)
Список pgsql-hackers
Mikhail Gribkov <youzhick@gmail.com> writes:
> Just for a more complete picture of the final state here.
> I have posted the described fix (for avoiding race condition in the tests)
> separately:
> https://commitfest.postgresql.org/45/4616/

It turns out that the TAP test for this feature (006_login_trigger.pl)
also has a race condition:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mamba&dt=2023-10-28%2003%3A33%3A28

The critical bit of the log is

ack Broken pipe: write( 14, 'SELECT 1;' ) at /usr/pkg/lib/perl5/vendor_perl/5.36.0/IPC/Run/IO.pm line 550.

It looks to me that what happened here is that the backend completed the
authentication handshake, and then the login trigger caused a FATAL exit,
and after than the connected psql session tried to send "SELECT 1" on
an already-closed pipe.  That failed, causing IPC::Run to panic.

mamba is a fairly slow machine and doubtless has timing a bit different
from what this test was created on.  But I doubt there is any way to make
this behavior perfectly stable across a range of machines, so I recommend
just removing the test case involving a fatal exit.

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Issues with Information_schema.views
Следующее
От: Denis Smirnov
Дата:
Сообщение: Re: Use virtual tuple slot for Unique node