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

From Tom Lane
Subject Re: stat() vs ERROR_DELETE_PENDING, round N + 1
Date
Msg-id 2243087.1630581161@sss.pgh.pa.us
Whole thread Raw
In response to Re: 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
Thomas Munro <thomas.munro@gmail.com> writes:
> On Thu, Sep 2, 2021 at 10:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That seems quite horrid :-(.  But if it works, doesn't that mean that
>> somewhere we are opening a problematic file without the correct
>> sharing flags?

> I'm no expert, but not AFAICS.  We managed to delete the file while
> some other backend had it open, which FILE_SHARE_DELETE allowed.  We
> just can't open it or create a new file with the same name until it's
> really gone (all handles closed).

Right, but we shouldn't ever need to access such a file --- we couldn't do
so on Unix, certainly.  So for the open() case, it's sufficient to return
ENOENT, and the problem is only to make sure that that's what we return if
the underlying error is ERROR_DELETE_PENDING.

It's harder if the desire is to create a new file of the same name.
I'm inclined to think that the best answer might be "if it hurts,
don't do that".  We should not have such a case for ordinary relation
files or WAL files, but maybe there are individual other cases where
some redesign is indicated?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [PATCH] test/ssl: rework the sslfiles Makefile target
Next
From: Daniel Gustafsson
Date:
Subject: Re: Online verification of checksums