Re: Refactoring the checkpointer's fsync request queue

On Tue, Jan 22, 2019 at 12:17 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

> Unfortunately, unless something has changed recently, that patch is
> *not* sufficient to really solve the issue - we don't guarantee that
> there's always an fd preventing the necessary information from being
> evicted from memory:

But we can't lose an FD without either closing it or suffering an
abrupt termination that would trigger a PANIC, can we? And close()
always calls fsync(). And I thought our "PANIC on fsync" patch paid
attention to close(). How do you see this happening???

> Note that we might still lose the error if the inode gets evicted from
> the cache before anything can reopen it, but that was the case before
> errseq_t was merged. At LSF/MM we had some discussion about keeping
> inodes with unreported writeback errors around in the cache for longer
> (possibly indefinitely), but that's really a separate problem"
>
> And that's entirely possibly in postgres.

Is it possible for an inode to be evicted while there is an open FD
referencing it?

> The commit was dicussed on list too, btw...

Can you point to a post explaining how the inode can be evicted?
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/