Re: Windows buildfarm members vs. new async-notify isolation test
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
Magnus Hagander <magnus@hagander.net>,
Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
Mark Dilger <hornschnorter@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-08-30T03:21:45Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > I made a thing to watch out for low probability BF failures and it > told me that a similar failure in async-notify might have reappeared > on brolga: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=brolga&dt=2020-07-15%2008:30:11 > | REL_10_STABLE > [ etc ] Hm, interesting. None of these examples show an actual *failure* to receive a notification, unlike the example that began this thread. So it seems unlikely that back-patching 16114f2ea would help. What we are seeing here, instead, is delayed timing of notify receipt(s). I suspect that this is a variant of the issue described over here: https://www.postgresql.org/message-id/flat/2527507.1598237598%40sss.pgh.pa.us I didn't have a great idea about how to fix it reliably in insert-conflict-specconflict, and I lack one here too :-(. It's interesting though that your examples are all in v10 or older. Could we have done something that indirectly fixes the problem since then? Or is that just chance? regards, tom lane
Commits
-
Use only one thread to handle incoming signals on Windows.
- 16114f2ea0c0 13.0 landed
-
Fix race condition in our Windows signal emulation.
- df44e411c008 9.6.17 landed
- 7309e75fa956 9.4.26 landed
- 1a0c65120137 9.5.21 landed
- 096ea540e1e9 10.12 landed
- 2ed302ab9703 11.7 landed
- 28e6a2fd6358 13.0 landed
- 001362cfdc94 12.2 landed