Hi,
On Wed, Mar 25, 2026 at 08:46:23AM +0900, Michael Paquier wrote:
> On Tue, Mar 24, 2026 at 04:09:37PM -0400, Andres Freund wrote:
> > The test is extremely unstable on windows. On CI 10/16 runs since the test in
> > failed due to it, afaict.
Thanks for the warning!
> I am not surprised by that. Windows is good in catching race
> conditions.
>
> > I don't see how a test with a timeout setting that's anywhere remotely close
> > to 10ms could be expected to be stable.
>
> Well, the low value of deadlock_timeout is not the problem.
Yeah, there are other tests making use of a 10ms deadlock timeout.
> This test would be better if rewritten as a TAP test, I guess, with a
> NOTICE injection point before the CheckDeadLock() call in ProcSleep()
> to make sure that the second session processes the deadlock timeout
> request while it is waiting on its lock to be acquired. One trickier
> part is that we only care about the deadlock_timeout in s2, because we
> want to measure the wait it has waited until the lock could be
> acquired, meaning that we should make s1 use a large deadlock_timeout
> to avoid interferences with a global injpoint.
>
> I don't have the credits to test that in the CI for this month,
> unfortunately, and this creates noise in the CI for the work of other
> folks in this release cycle, so I am going to remove this test for
> now.
Thanks for the test removal. I created an open item for v19 so that we
don't forget to re-add a new version of the tests. I'll work on it.
[1]: https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
