From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: IPC::Run accepts bug reports |
Date: | 2024-10-04 18:57:48 |
Message-ID: | 20241004185748.22.nmisch@google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 04, 2024 at 02:00:00PM +0300, Alexander Lakhin wrote:
> sub _read {
> ...
> my $r = POSIX::read( $_[0], $s, 10_000 );
> croak "$!: read( $_[0] )" if not($r) and !$!{EINTR};
>
> That is, EINTR kind of recognized as an expected error, but there is no
> retry in this case. Thus, with the following modification, which simulates
> read() failed with EINTR:
> sub _read {
> confess 'undef' unless defined $_[0];
> my $s = '';
> - my $r = POSIX::read( $_[0], $s, 10_000 );
> + my $r;
> +if (int(rand(100)) == 0)
> +{
> + $r = 0; $! = Errno::EINTR;
> +}
> +else
> +{
> + $r = POSIX::read( $_[0], $s, 10_000 );
> +}
> croak "$!: read( $_[0] )" if not($r) and !$!{EINTR};
>
> I can see failures like the one in question when running that test.
That makes sense. Would you file this at
https://github.com/cpan-authors/IPC-Run/issues? I suppose that code should
become roughly:
do { $r = POSIX::read(...) } while (!defined($r) && $!{EINTR});
croak ... unless defined($r);
> Perhaps, I could reproduce the issue with a program, that sends signals
> to running (pgbench) processes (and thus interrupts read()), if it makes
> sense.
That should work. Best would be an IPC::Run test case, like the existing
t/eintr.t that makes select() report EINTR. That said, IPC::Run could adopt
the retry without a test.
> [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=indri&dt=2024-10-02%2002%3A34%3A16
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-10-04 20:46:44 | Re: ECPG cleanup and fix for clang compile-time problem |
Previous Message | Heikki Linnakangas | 2024-10-04 18:41:13 | Re: Refactoring postmaster's code to cleanup after child exit |