Re: backtrace_on_internal_error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: backtrace_on_internal_error
Date: 2023-12-09 17:41:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> I was wondering about that too. But if we do so, why not also do it for
>> writes?

> Writes don't act that way, do they? EOF on a pipe gives you an error,
> not silently reporting that zero bytes were written and leaving you
> to retry indefinitely.

On further reflection I realized that you're right so far as the SSL
code path goes, because SSL_write() can involve physical reads as well
as writes, so at least in principle it's possible that we'd see EOF
reported this way from that function.

Also, the libpq side does need work of the same sort, leading to the
v2-0001 patch attached.

I also realized that we have more or less the same problem at the
caller level, allowing a similar failure for non-SSL connections.
So I'm also proposing 0002 attached. Your results from aggregated
logs didn't show "could not receive data from client: Success" as a
common case, but since we weren't bothering to zero errno beforehand,
it's likely that such failures would show up with very random errnos.

I took a quick look at the GSSAPI code path too, but it seems not to
add any new assumptions of this sort.

regards, tom lane

Attachment Content-Type Size
v2-0001-handle-openssl-returning-errno-zero.patch text/x-diff 2.6 KB
v2-0002-handle-zero-errno-generally.patch text/x-diff 2.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2023-12-09 17:59:54 Re: Schema variables - new implementation for Postgres 15
Previous Message Andres Freund 2023-12-09 17:10:00 Re: backtrace_on_internal_error