Robert Haas <[email protected]> writes:
> On Sun, May 20, 2012 at 2:12 PM, Alvaro Herrera
> <[email protected]> wrote:
>>> Yeah, an enum would be nicer than an additional GUC. I kinda keep forgetting
>>> that we have those. Though to bikeshed, the GUC should probably be just
>>> called
>>> 'zero_pages' and take the values 'never', 'missing', 'unreadable' ;-)
>> Sounds reasonable to me ..
> It seems like it would be nicer to have a setting that somehow makes
> the system disregard errors and soldier on rather than actively
> destroying your data. Not that I have an exact design in mind, but
> zero_damaged_pages is a really fast way to destroy your data.
If we were sure that the kernel error was permanent, then this argument
would be moot: the data is gone already. The scary thought here is that
it might be a transient error, such as a not-always-repeatable kernel
bug. In that case, zeroing the page would indeed lose data that had
been recoverable before.
I'm not entirely sure how we would "soldier on" though; there is no good
reason to think that the kernel has loaded any data at all into
userspace when read() fails.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
