Re: drop/truncate table sucks for large values of shared buffers

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.