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
