Re: [BUG] Logical replica crash if there was an error in a function.
От | Anton A. Melnikov |
---|---|
Тема | Re: [BUG] Logical replica crash if there was an error in a function. |
Дата | |
Msg-id | 2adbd7bc-e028-a4f6-fc3c-389a90e41a95@inbox.ru обсуждение исходный текст |
Ответ на | Re: [BUG] Logical replica crash if there was an error in a function. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUG] Logical replica crash if there was an error in a function.
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: