Re: On login trigger: take three
От | Alexander Korotkov |
---|---|
Тема | Re: On login trigger: take three |
Дата | |
Msg-id | CAPpHfds1WuQOiqafsFjH8o_D1jVKjgH2im+VJb-NXtARvxUBqw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: On login trigger: take three (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: On login trigger: take three
Re: On login trigger: take three |
Список | pgsql-hackers |
On Sun, Oct 29, 2023 at 6:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. Makes sense. Are you good with the attached patch? ------ Regards, Alexander Korotkov
Вложения
В списке pgsql-hackers по дате отправления: