Re: make -C src/test/isolation failure in index-killtuples due to btree_gist
| От | Andres Freund |
|---|---|
| Тема | Re: make -C src/test/isolation failure in index-killtuples due to btree_gist |
| Дата | |
| Msg-id | rsgolpgcheedmh62mhvrpbka4skgczw5x7gf3wjdzyye7mnm4m@uimvk3wrq5ni обсуждение исходный текст |
| Ответ на | Re: make -C src/test/isolation failure in index-killtuples due to btree_gist (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: make -C src/test/isolation failure in index-killtuples due to btree_gist
|
| Список | pgsql-hackers |
Hi, On 2025-11-18 08:40:46 +0900, Michael Paquier wrote: > On Tue, Nov 18, 2025 at 08:31:41AM +0900, Michael Paquier wrote: > > Hmm. We should try to conclude over the benefit of TAP over > > isolation, and merge both patches together if the consensus is towards > > a TAP test. > > > > The isolation test feels much cleaner to me in terms of clarity and > > debugging output compared to the suggested TAP test as there are many > > SQL sequences the test depends on. Other opinions? > > By the way, an extra argument in favor of an isolation test here: the > proposed TAP tests only wants to make sure that replay is able to > finish on a standby, we don't query it. I think we should eventually extend the test to run amcheck etc on both primary and standby. > We are already doing the same in 027_stream_regress.pl for the main > regression test suite, and we could expand this TAP test or add a new one > that grabs the isolation test suite and runs it in a TAP test with a standby > plugged. I don't think we should add new things to 027_stream_regress, it's already one of the two slowest tests and, at least for me, often the test that takes the longest to complete in a testrun. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: