Re: psql - add SHOW_ALL_RESULTS option

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: psql - add SHOW_ALL_RESULTS option
Дата
Msg-id 2570e2ae-fa0f-aac9-f72f-bb59a9983a20@enterprisedb.com
обсуждение исходный текст
Ответ на Re: psql - add SHOW_ALL_RESULTS option  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы 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>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Nancarrow
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side
Следующее
От: "osumi.takamichi@fujitsu.com"
Дата:
Сообщение: RE: Skipping logical replication transactions on subscriber side