Simon Riggs <si...@2ndquadrant.com> writes:
> On 27 June 2015 at 15:10, Tom Lane <t...@sss.pgh.pa.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?)
> If that is true, then our reliance on lseek elsewhere could also cause data
> loss, for example by failing to scan data during a seq scan.
The lseek point was a for-example, not the entire universe of possible
problem sources for this patch. (Also, underestimating the EOF point in
a seqscan is normally not an issue since any rows in a just-added page
are by definition not visible to the scan's snapshot. But I digress.)
> The consequences of failure of lseek in this case are nowhere near as dire,
> since by definition the data is being destroyed by the user.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
