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