Re: backtrace_on_internal_error
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-12-20T10:30:01Z
Lists: pgsql-hackers
Hi, On 2023-12-20 10:08:42 +0100, Jelte Fennema-Nio wrote: > On Sun, 10 Dec 2023 at 00:14, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I'm not actually sure that the fe-secure.c part of v3-0002 is > > necessary, because it's guarding plain recv(2) which really shouldn't > > return -1 without setting errno. Still, it's a pretty harmless > > addition. > > v3-0002 seems have a very similar goal to v23-0002 in my non-blocking > and encrypted cancel request patchset here: > https://www.postgresql.org/message-id/flat/CAGECzQQirExbHe6uLa4C-sP%3DwTR1jazR_wgCWd4177QE-%3DVFDw%40mail.gmail.com#0b6cc1897c6d507cef49a3f3797181aa > > Would it be possible to merge that on instead or at least use the same > approach as that one (i.e. return -2 on EOF). Otherwise I have to > update that patchset to match the new style of communicating that > there is an EOF. Also I personally think a separate return value for > EOF clearer when reading the code than checking for errno being 0. Tom's patch imo doesn't really introduce anything really new - we already deal with EOF that way in other places. And it's how the standard APIs deal with the issue. I'd not design it this way on a green field, but given the current state Tom's approach seems more sensible... Greetings, Andres Freund
Commits
-
Add GUC backtrace_on_internal_error
- a740b213d4b4 17.0 landed
-
Fix variable name and comment
- 541e8f14a185 17.0 landed
-
Be more wary about OpenSSL not setting errno on error.
- ebbd499d4b55 16.2 landed
- 87b46ad90491 13.14 landed
- 551d4b28e445 15.6 landed
- 271d24f31ddd 12.18 landed
- 0a5c46a7a488 17.0 landed
- 07ce2432682d 14.11 landed