On Tue, Oct 18, 2022 at 3:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Isn't it already the case (or could be made so) that relation file
> removal happens only in the checkpointer? I wonder if we could
> get to a situation where we can interlock file removal just by
> commanding the checkpointer to not do it for awhile. Then combining
> that with caching readdir results (to narrow the window in which we
> have to stop the checkpointer) might yield a solution that has some
> credibility. This scheme doesn't attempt to prevent file creation
> concurrently with a readdir, but you'd have to make some really
> adverse assumptions to believe that file creation would cause a
> pre-existing entry to get missed (as opposed to getting scanned
> twice). So it might be an acceptable answer.
I believe that individual backends directly remove all relation forks
other than the main fork and all segments other than the first one.
The discussion on various other threads has been in the direction of
trying to standardize on moving that last case out of the checkpointer
- i.e. getting rid of what Thomas dubbed "tombstone" files - which is
pretty much the exact opposite of this proposal. But even apart from
that, I don't think this would be that easy to implement. If you
removed a large relation, you'd have to tell the checkpointer to
remove many files instead of just 1. That sounds kinda painful: it
would be more IPC, and it would delay file removal just so that we can
tell the checkpointer to delay it some more.
And I don't think we really need to do any of that. We could invent a
new kind of lock tag for <dboid/tsoid> combination. Take a share lock
to create or remove files. Take an exclusive lock to scan the
directory. I think that accomplishes the same thing as your proposal,
but more directly, and with less overhead. It's still substantially
more than NO overhead, though.
--
Robert Haas
EDB: http://www.enterprisedb.com
