Re: backtrace_on_internal_error

From: Andres Freund <andres(at)anarazel(dot)de>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 10:30:01
Message-ID: 20231220103001.bemhwy73uwiawakk@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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(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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Drouvot, Bertrand 2023-12-20 10:40:03 Re: Function to get invalidation cause of a replication slot.
Previous Message Alexander Kukushkin 2023-12-20 10:29:24 Re: Allow custom parameters with more than one dot in config files.