Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 3 Oct 2022 09:40:20 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
	Andres Freund <andres@anarazel.de>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: pg_upgrade test failure
Message-ID: <YzovdL3lqhmorvl0@paquier.xyz>
References: <E1oXuu7-0005bU-55@gemulon.postgresql.org>
 <20220919213217.ptqfdlcc5idk5xup@awork3.anarazel.de>
 <20220920013122.GA31833@telsasoft.com>
 <CA+hUKGJSkt3nx35uwpYX8D+cAZT38gk++btCp2Tz+uibH+Y1PA@mail.gmail.com>
 <CA+hUKG+H-q78LxD20UOVyJbP1_idyocj6va_v1TF4RnN9JZa+w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="0sVtsBD4PEjwXGZU"
Content-Disposition: inline
In-Reply-To: 
 <CA+hUKG+H-q78LxD20UOVyJbP1_idyocj6va_v1TF4RnN9JZa+w@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/YzovdL3lqhmorvl0%40paquier.xyz>
Precedence: bulk


--0sVtsBD4PEjwXGZU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Oct 03, 2022 at 12:10:06PM +1300, Thomas Munro wrote:
> I think something like the attached should do the right thing for
> STATUS_DELETE_PENDING (sort of "ENOENT-in-progress").  unlink() goes
> back to being blocking (sleep+retry until eventually we reach ENOENT
> or we time out and give up with EACCES), but we still distinguish it
> from true ENOENT so we have a fast exit in that case.  This is passing
> CI, but not tested yet.

    if (lstat(path, &st) < 0)
-       return -1;
+   {
+       if (lstat_error_was_status_delete_pending())
+           is_lnk = false;
+       else
+           return -1;
+   }
+   else
+       is_lnk = S_ISLNK(st.st_mode);
Sorry, I don't remember all the details in this area, but a directory
can never be marked as STATUS_DELETE_PENDING with some of its contents
still inside, right?  If it has some contents, forcing unlink() all
the time would be fine?

> One ugly thing in this patch is that it has to deal with our
> historical mistake (?) of including Windows headers in this file in
> Cygwin builds for no reason and thus getting WIN32 defined on a
> non-WIN32 build, as I've complained about before[1] but not yet tidied
> up.

Your proposal remains local to dirmod.c, so that does not sound like a
big deal to me for the time being.
--
Michael

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

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

iQIzBAEBCAAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmM6L3QACgkQnvQgOdby
QH2oaRAAqoxoTfvjxyEPbi3oAACTli0ju7u6BKe/2WaNtArFbKmva7IKwQ6hMtJr
ame5E8nxHKWxikmPA3qO33+4TXgdUbJhXCD3pE8yKgkennOA5L78oyvTbYjfUiIG
0u1DiijRfn94sxC/5RT0g5m+dC4se7ogm7ZqvrCjG1ZF6zLwRajfr/43HuyqBId1
1FgAf+83ex5yReHEwcxMjmaot0FDDUEBIgQWi7iqHUP0N8Zy84fM/9WX1wxo1vRz
88HWO8R4FvrtzUyzdzIhUBK90zfebpiI1ved+TNjdt/m9aomQ0aSqxpaN14yZBnO
27WCbM5e657tgTMllIW8n+S6gZNEYHjecPCOpc+iX4uaFl8ltBmi9zgyGu+Ck9JW
zVHUbu28LeFkL3xRwadsgQ8ORa37ZeipjahQPE0NwmAlTG32fDTpCTPZMB7D+fAn
/4Wbg5R/abPgZAt69rLtcHrmXeiZD8D/DjPRuEmzw88QOAM3PdloDX1EF84Z041O
XuRwhoPg+o9u/7906q/AoeFm9zQrJtW2sHY5pdQdQ0NEGryEhMy12QK7hIuldpmP
lHhhyuQJOKV34LJbsr6hhEIU0nDpcjqdX2J4gydQs+nrzBpspZMj3i4yKgDSx+AU
3ZfIW1vEMJ41GawV97pTBTkQ1sT1Ujx0yD566RoncUFzf/0qd/k=
=KrrW
-----END PGP SIGNATURE-----

--0sVtsBD4PEjwXGZU--