Re: stat() vs ERROR_DELETE_PENDING, round N + 1 - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: stat() vs ERROR_DELETE_PENDING, round N + 1
Date
Msg-id CA+hUKGJn_y77qb+nFBED70OXP5px2Gn+buzbV-bQ4rm2u95yAQ@mail.gmail.com
Whole thread Raw
In response to Re: stat() vs ERROR_DELETE_PENDING, round N + 1  (Michael Paquier <michael@paquier.xyz>)
Responses Re: stat() vs ERROR_DELETE_PENDING, round N + 1  (Alexander Lakhin <exclusion@gmail.com>)
List pgsql-hackers
On Mon, Sep 6, 2021 at 6:36 PM Michael Paquier <michael@paquier.xyz> wrote:
> Having a non-invasive fix for this long-standing issue would be really
> great, even if that means reducing the scope of systems where this can
> be fixed.

I hope those patches fix at least the basebackup problem on all
relevant OS versions, until the better POSIX thing is everywhere (they
can't fix all related problems though, since zombie files still stop
you creating new ones with the same name or deleting the containing
directory).   I didn't try to find out how far back those APIs go, but
they look ancient/fundamental and widely used by other software...
But do they qualify as non-invasive?

> The last time I poked at the bear (54fb8c7d), there was a test posted
> by Alexander Lakhin that was really useful in making sure that
> concurrency is correctly handled when a file is unlinked:
> https://www.postgresql.org/message-id/c3427edf-d7c0-ff57-90f6-b5de3bb62709@gmail.com

Thanks.  It's a confusing topic with many inconclusive threads.

> It worked with VS but not on MinGW.  How does your patch react to this
> test?

Thanks.  Adding Alexander in CC in case he has ideas/feedback.



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Allow escape in application_name
Next
From: Pavel Luzanov
Date:
Subject: Re: psql: \dl+ to list large objects privileges