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

On Sun, Jun 28, 2015 at 9:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> > On Sat, Jun 27, 2015 at 7:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> I don't like this too much because it will fail badly if the caller
> >> is wrong about the maximum possible page number for the table, which
> >> seems not exactly far-fetched. (For instance, remember those kernel
bugs
> >> we've seen that cause lseek to lie about the EOF position?)
>
> > Considering we already have exclusive lock while doing this operation
> > and nobody else can perform write on this file, won't closing and
> > opening it again would avoid such problems.
>
> On what grounds do you base that touching faith?

Sorry, but I don't get what problem do you see in this touching?

> Quite aside from
> outright bugs, having lock on a table has nothing to do with whether
> low-level processes such as the checkpointer can touch it.
>

I thought that this problem (lseek lie about EOF) would only occur
if there is a recent extension to the file or does mere writes to existing
pages could also cause this problem?

Though we should ideally take care of any failures of OS API's especially
if they could lead to data loss, however not sure if we can do that reliably
in all possible cases. Can we safely guarantee that as we haven't
encountered any other such problem in any other API, so everything is good.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com