Re: On login trigger: take three - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: On login trigger: take three
Date
Msg-id CAPpHfds1WuQOiqafsFjH8o_D1jVKjgH2im+VJb-NXtARvxUBqw@mail.gmail.com
Whole thread Raw
In response to Re: On login trigger: take three  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: On login trigger: take three
Re: On login trigger: take three
List 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

Attachment

pgsql-hackers by date:

Previous
From: Mingli Zhang
Date:
Subject: Re: COPY TO (FREEZE)?
Next
From: Tom Lane
Date:
Subject: Re: On login trigger: take three