Re: [BUG] Logical replica crash if there was an error in a function. - Mailing list pgsql-hackers

From Anton A. Melnikov
Subject Re: [BUG] Logical replica crash if there was an error in a function.
Date
Msg-id 2adbd7bc-e028-a4f6-fc3c-389a90e41a95@inbox.ru
Whole thread Raw
In response to Re: [BUG] Logical replica crash if there was an error in a function.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUG] Logical replica crash if there was an error in a function.
List pgsql-hackers
Thanks a lot for the fast reply!

On 03.11.2022 18:29, Tom Lane wrote:
> If we were just adding a
> query or two to an existing scenario, that could be okay; but spinning
> up and syncing a whole new primary and standby database is *expensive*
> when you multiply it by the number of times developers and buildfarm
> animals are going to run the tests in the future.
>

On 15.11.2022 04:59, Tom Lane wrote:
> "Anton A. Melnikov" <aamelnikov@inbox.ru> writes:
>> On 02.11.2022 21:02, Tom Lane wrote:
>>> I don't think the cost of that test case is justified by the tiny
>>> probability that it'd ever catch anything.
>
>> Seems it is possible to do a test without these remarks. The attached
>> test uses existing nodes and checks the specific error message.
>
> My opinion remains unchanged: this would be a very poor use of test
> cycles.

Sorry, i didn't fully understand what is required and
added some functions to the test that spend extra cpu time. But i found
that it is possible to make a test according to previous remarks by adding
only a few extra queries to an existent test without any additional syncing.

Experimentally, i could not observe any significant difference in
CPU usage due to this test addition.
The difference in the CPU usage was less than standard error.
See 100_bugs-CPU-time.txt attached.

>> Additionally
>> i've tried to reduce overall number of nodes previously
>> used in this test in a similar way.
>
> Optimizing existing tests isn't an answer to that.  We could
> install those optimizations without adding a new test case.

Oh sure! Here is a separate patch for this optimization:
https://www.postgresql.org/message-id/eb7aa992-c2d7-6ce7-4942-0c784231a362%40inbox.ru
On the contrary with previous case in that one the difference in the CPU usage
during 100_bugs.pl is essential; it decreases approximately by 30%.


With the best wishes!

-- 
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: const qualifier for list APIs
Next
From: Simon Riggs
Date:
Subject: Re: Reducing power consumption on idle servers