On 30 June 2015 at 05:02, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Mon, Jun 29, 2015 at 7:18 PM, Simon Riggs <si...@2ndquadrant.com> > wrote: > > > > On 28 June 2015 at 17:17, Tom Lane <t...@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/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
