Hi, On Tue, Feb 27, 2024 at 04:49:03PM +0500, Andrey M. Borodin wrote: > Hi, > > > On 27 Feb 2024, at 16:08, Bertrand Drouvot <bertranddrouvot...@gmail.com> > > wrote: > > > > On Tue, Feb 27, 2024 at 11:00:10AM +0500, Andrey M. Borodin wrote: > >> > >> But, AFAICS, the purpose is the same: wait until event happened. > > > > I think it's easier to understand the tests (I mean what the purpose of the > > injection points are) if we don't use an helper function. While the helper > > function would make the test easier to read / cleaner, I think it may make > > them > > more difficult to understand as 'await_injection_point' would probably be > > too > > generic. > > For the record: I’m fine if there is no such function. > There will be at least one implementation of this function in every single > test with waiting injection points. > That’s the case where we might want something generic. > What the specific there might be? The test can check that > - conditions are logged > - injection point reached in specific backend (e.g. checkpointer) > etc > > I doubt that this specific checks worth cleanness of the test. And > sacrificing test readability in favour of teaching reader what injection > points are sounds strange.
I'm giving a second thought and it does not have to be exclusive, for example in this specific test we could: 1) check that the injection point is reached with the helper (querying pg_stat_activity looks good to me) And 2) check in the log So even if two checks might sound "too much" they both make sense to give 1) better readability and 2) better understanding of the test. So, I'm ok with the new helper too. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
