On Tue, Jan 22, 2019 at 12:17 PM Andres Freund <andres@anarazel.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/