Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:

On Tue, Apr 5, 2022 at 10:24 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Tue, Apr 5, 2022 at 2:18 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > 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.
>
> The checkpointer never takes heavyweight locks, so the opportunity
> you're describing can't arise.

<thinks harder> Hmm, oh, you probably meant the buffer interlocking
in SyncOneBuffer(). It's true that my most recent patch throws away
more requests than it could, by doing the level check at the end of
the loop over all buffers instead of adding some kind of
DropPendingWritebacks() in the barrier handler. I guess I could find
a way to improve that, basically checking the level more often instead
of at the end, but I don't know if it's worth it; we're still throwing
out an arbitrary percentage of writeback requests.