On Fri, Apr 1, 2022 at 5:03 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Another idea would be to call a new function DropPendingWritebacks(),
> and also tell all the SMgrRelation objects to close all their internal
> state (ie the fds + per-segment objects) but not free the main
> SMgrRelationData object, and for good measure also invalidate the
> small amount of cached state (which hasn't been mentioned in this
> thread, but it kinda bothers me that that state currently survives, so
> it was one unspoken reason I liked the smgrcloseall() idea). Since
> DropPendingWritebacks() is in a rather different module, perhaps if we
> were to do that we'd want to rename PROCSIGNAL_BARRIER_SMGRRELEASE to
> something else, because it's not really a SMGR-only thing anymore.
I'm not sure that it really matters, but with the idea that I proposed
it's possible to "save" a pending writeback, if we notice that we're
accessing the relation with a proper lock after the barrier arrives
and before we actually try to do the writeback. With this approach we
throw them out immediately, so they're just gone. I don't mind that
because I don't think this will happen often enough to matter, and I
don't think it will be very expensive when it does, but it's something
to think about.
--
Robert Haas
EDB: http://www.enterprisedb.com
