Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 20 Oct 2025 17:38:14 +0900
From: Michael Paquier <michael@paquier.xyz>
To: vignesh C <vignesh21@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Random pg_upgrade 004_subscription test failure on drongo
Message-ID: <aPX09h2QbrPDKrS5@paquier.xyz>
References: 
 <CALDaNm3tjY44HoSwY84=XGEbTg0ruVfD4hAMTm=TgBqVysH4Qw@mail.gmail.com>
 <cd3189f8-aaed-4ef6-a6b6-da72c1251f34@iki.fi>
 <CALDaNm2y+nf-V9tjKwvbPprobZs1t_UrcCpJ0qYD5-KkOUFAyg@mail.gmail.com>
 <CALDaNm1NtWVosSSb9mp3OKic60em5HF2zmURC77MLWyYLMWqyw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="uTrA1N9CnZhT85Xu"
Content-Disposition: inline
In-Reply-To: 
 <CALDaNm1NtWVosSSb9mp3OKic60em5HF2zmURC77MLWyYLMWqyw@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aPX09h2QbrPDKrS5%40paquier.xyz>
Precedence: bulk


--uTrA1N9CnZhT85Xu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 22, 2025 at 02:28:35PM +0530, vignesh C wrote:
> CFBot reported an issue in one of the machines, here is an updated
> version for the same.

@@ -235,6 +248,9 @@ mdcreate(SMgrRelation reln, ForkNumber forknum, bool is=
Redo)
[...]
+#if defined(WIN32) && !defined(__CYGWIN__)
+            if (!retryattempted && pg_RtlGetLastNtStatus() =3D=3D STATUS_D=
ELETE_PENDING)
+            {
+                retryattempted =3D true;
+                WaitForProcSignalBarrier(EmitProcSignalBarrier(PROCSIGNAL_=
BARRIER_SMGRRELEASE));
+                goto retry;
+            }

Adding more WIN32-specific awesomeness into a single backend code path
that we try to make POSIX-consistent does not seem right to me,
because it may apply to more FDs opened than this one, no?  One code=20
path would be to enforce a signal in pgwin32_open_handle(), only when
we see a STATUS_DELETE_PENDING.  And there is a retry loop in
src/port/open.c in our wrapper, partially for this reason.

Like any failures of this type, how can we reliably make sure that
these issues are gone for sure?  Perhaps it would be time to have a
test module specified in concurrent file-system operations?  We could
hold into FDs while making backends wait, for example, with various
concurrent in-core calls stepping on each other..  Perhaps that would
be beneficial in the long-term knowing the number of platforms we need
to support.
--
Michael

--uTrA1N9CnZhT85Xu
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmj19PYACgkQnvQgOdby
QH0jPhAAki1fsK3S3CpM47KKsX2c7cqLOoCXvf1Y/YKgyM4VzPmlY2X+F9bK9U/d
ydXEVWYZrJjTc0MgYqCWpb5NYXjN6nSQXRIwpiajtNQOOZ3gyg1tYoitKxD/oOjW
Tzn1+SNxl1aU1oAusMLzquVzXaJYMJbP/Raf4+cwJSNoAhQLHnYdExJ78WIhtdJe
Q+35fIt8Kc2Appd94LZOdJj7a3BqVT1WaJdr8aLN9TKwavW7vixZ2b0KMSDmFHjQ
4FNF8KjRMHChXEWSjCeCBnAUQtSQNvk/1kDUoIsMd5s+ayHtrS1XpFGiyJgGgQmN
cFXNvbk+N/xnNWfW+Uf8nasVsEIkayzgsenieLnPwdVKgzg6O1N2iivB4FahK80B
JyymTAN+nq5+4Rbi4q2ejlSmDgtZHJOhQzEN51LOCzsQkkfRJJW5c1T/VPYfr1Vb
2P7lTConJix98opT7DIvMNWZL67veKMQIffjkjwTraypxMeaPwgvVYydL2hsTG9b
rEt8B/Uhintcfl/gzigSakCXm/haXCRnwfuLJOEM/wtwDBD7SN+e2O+zOEpjdV78
6CXU9Ow+BusXUbAhfKB4aNKhiUP4/c3utchQKz7+3Ta4bgMAMYM9jwMHmlov8m/q
iGUs3/TV/Op1ckKHfWoD+S4kjfFE2QM6zMHLkJ6tE0md9yTZGlc=
=1apq
-----END PGP SIGNATURE-----

--uTrA1N9CnZhT85Xu--