On Mon, Jun 29, 2015 at 7:18 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > > On 28 June 2015 at 17:17, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >> I'm not sure what you consider "dire", but missing a dirty buffer >> belonging to the to-be-destroyed table would result in the system being >> permanently unable to checkpoint, because attempts to write out the buffer >> to the no-longer-extant file would fail. You could only get out of the >> situation via a forced database crash (immediate shutdown), followed by >> replaying all the WAL since the time of the problem. In production >> contexts that could be pretty dire. > > > Yes, its bad, but we do notice that has happened. We can also put in code to specifically avoid this error at checkpoint time. > > If lseek fails badly then SeqScans would give *silent* data loss, which in my view is worse. Just added pages aren't the only thing we might miss if lseek is badly wrong. >
So for the purpose of this patch, do we need to assume that
lseek can give us wrong size of file and we should add preventive
checks and other handling for the same?
I am okay to change that way, if we are going to have that as assumption
in out code wherever we are using it or will use it in-future, otherwise
we will end with some preventive checks which are actually not required.
They're preventative checks. You always hope it is wasted effort.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
