Re: Checking for missing heap/index files - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Checking for missing heap/index files
Date
Msg-id CA+TgmoawhN321eCzmG_JJvRxei9w9C5mQ4r1iAU29w41x_7fOw@mail.gmail.com
Whole thread Raw
In response to Re: Checking for missing heap/index files  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Checking for missing heap/index files
List pgsql-hackers
On Tue, Oct 18, 2022 at 12:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> There is no text suggesting that it's okay to miss, or to double-return,
> an entry that is present throughout the scan.  So I'd interpret the case
> you're worried about as "forbidden by POSIX".  Of course, it's known that
> NFS fails to provide POSIX semantics in all cases --- but I don't know
> if this is one of them.

Yeah, me neither. One problem I see is that, even if the behavior is
forbidden by POSIX, if it happens in practice on systems people
actually use, then it's an issue. We even have documentation saying
that it's OK to use NFS, and a lot of people do -- which IMHO is
unfortunate, but it's also not clear what the realistic alternatives
are. It's pretty hard to tell people in 2022 that they are only
allowed to use PostgreSQL with local storage.

But to put my cards on the table, it's not so much that I am worried
about this problem myself as that I want to know whether we're going
to do anything about it as a project, and if so, what, because it
intersects a patch that I'm working on. So if we want to readdir() in
one fell swoop and cache the results, I'm going to go write a patch
for that. If we don't, then I'd like to know whether (a) we think that
would be theoretically acceptable but not justified by the evidence
presently available or (b) would be unacceptable due to (b1) the
potential for increased memory usage or (b2) some other reason.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: [RFC] building postgres with meson - v13
Next
From: Peter Geoghegan
Date:
Subject: Re: effective_multixact_freeze_max_age issue