Re: psql - add SHOW_ALL_RESULTS option

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: psql - add SHOW_ALL_RESULTS option
Date: 2022-03-23 12:58:36
Message-ID: alpine.DEB.2.22.394.2203231342180.3205455@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello Peter,

>> Attached v17 is another try. The point is to record the current status,
>> whatever it is, buggy or not, and to update the test when libpq fixes
>> things, whenever this is done.
> [...]
> The expected output (which passes) contains this line twice:
> psql:<stdin>:2: FATAL: terminating connection due to administrator command
> psql:<stdin>:2: FATAL: terminating connection due to administrator command

> If I paste this test case into current master without your patch, I only get
> this line once. So your patch is changing this output. The whole point of
> the libpq fixes was to not have this duplicate output. So I think something
> is still wrong somewhere.

Hmmm. Yes and no:-)

The previous path inside libpq silently ignores intermediate results, it
skips all results to keep only the last one. The new approach does not
discard resultss silently, hence the duplicated output, because they are
actually there and have always been there in the first place, they were
just ignored: The previous "good" result is really a side effect of a bad
implementation in a corner case, which just becomes apparent when opening
the list of results.

So my opinion is still to dissociate the libpq "bug/behavior" fix from
this feature, as they are only loosely connected, because it is a very
corner case anyway.

An alternative would be to remove the test case, but I'd prefer that it is

If you want to wait for libpq to provide a solution for this corner case,
I'm afraid that "never" is the likely result, especially as no test case
exercices this path to show that there is a problem somewhere, so nobody
should care to fix it. I'm not sure it is even worth it given the highly
special situation which triggers the issue, which is not such an actual
problem (ok, the user is told twice that there was a connection loss, no
big deal).


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2022-03-23 13:03:18 Re: make MaxBackends available in _PG_init
Previous Message Bharath Rupireddy 2022-03-23 12:55:23 Re: pg_walinspect - a new extension to get raw WAL data and WAL stats