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+hUKG+PUp1xY+-XaTi_pD=7wgOry3Q4DNH9LDr+7g-haPcD1A@mail.gmail.com
Whole thread Raw
In response to stat() vs ERROR_DELETE_PENDING, round N + 1  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: stat() vs ERROR_DELETE_PENDING, round N + 1
List pgsql-hackers
On Thu, Sep 2, 2021 at 10:10 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> Perhaps we need some combination of the old way (that apparently knew
> how to detect pending deletes) and the new way (that knows about large
> files)?

I tried that, but as far as I can tell, the old approach didn't really
work either :-(

A disruptive solution that works in my tests: we could reuse the
global barrier proposed in CF #2962.  If you see EACCES, ask every
backend to close all vfds at their next CFI() and wait for them all to
finish, and then retry.  If you get EACCES again it really means
EACCES, but you'll very probably get ENOENT.

The cheapest solution would be to assume EACCES really means ENOENT,
but that seems unacceptably incorrect.

I suspect it might be possible to use underdocumented/unstable NtXXX()
interfaces to get at the information, but I don't know much about
that.

Is there another way that is cheap, correct and documented?



pgsql-hackers by date:

Previous
From: "kuroda.hayato@fujitsu.com"
Date:
Subject: RE: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name)
Next
From: Tom Lane
Date:
Subject: Re: stat() vs ERROR_DELETE_PENDING, round N + 1