Re: psql - add SHOW_ALL_RESULTS option - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: psql - add SHOW_ALL_RESULTS option
Date
Msg-id 2570e2ae-fa0f-aac9-f72f-bb59a9983a20@enterprisedb.com
Whole thread Raw
In response to Re: psql - add SHOW_ALL_RESULTS option  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: psql - add SHOW_ALL_RESULTS option  (Daniel Gustafsson <daniel@yesql.se>)
Re: psql - add SHOW_ALL_RESULTS option  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On 02.10.21 16:31, Fabien COELHO wrote:
>> Attached v9 integrates your tests and makes them work.
> 
> Attached v11 is a rebase.

This patch still has a few of the problems reported earlier this year.

In [0], it was reported that certain replication commands result in 
infinite loops because of faulty error handling.  This still happens.  I 
wrote a test for it, attached here.  (I threw in a few more basic tests, 
just to have some more coverage that was lacking, and to have a file to 
put the new test in.)

In [1], it was reported that server crashes produce duplicate error 
messages.  This also still happens.  I didn't write a test for it, maybe 
you have an idea.  (Obviously, we could check whether the error message 
is literally there twice in the output, but that doesn't seem very 
general.)  But it's easy to test manually: just have psql connect, shut 
down the server, then run a query.

Additionally, I looked into the Coverity issue reported in [2].  That 
one is fixed, but I figured it would be good to be able to check your 
patches with a static analyzer in a similar way.  I don't have the 
ability to run Coverity locally, so I looked at scan-build and fixed a 
few minor warnings, also attached as a patch.  Your current patch 
appears to be okay in that regard.


[0]: 
https://www.postgresql.org/message-id/69C0B369-570C-4524-8EE4-BCCACECB6BEE@amazon.com

[1]: https://www.postgresql.org/message-id/2902362.1618244606@sss.pgh.pa.us

[2]: https://www.postgresql.org/message-id/2680034.1618157764@sss.pgh.pa.us

Attachment

pgsql-hackers by date:

Previous
From: Greg Nancarrow
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Skipping logical replication transactions on subscriber side