From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: backtrace_on_internal_error |
Date: | 2023-12-20 09:08:42 |
Message-ID: | CAGECzQSadnx7qnNPNPwkMMXv42NGKA2_gc3PqQ=SBnH1RzeCcQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 10 Dec 2023 at 00:14, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jelte Fennema-Nio | 2023-12-20 09:30:33 | Re: backtrace_on_internal_error |
Previous Message | Andrei Lepikhov | 2023-12-20 09:02:58 | Re: introduce dynamic shared memory registry |