Re: read() returns ERANGE in Mac OS X
От | Tom Lane |
---|---|
Тема | Re: read() returns ERANGE in Mac OS X |
Дата | |
Msg-id | 17911.1337617408@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: read() returns ERANGE in Mac OS X (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: read() returns ERANGE in Mac OS X
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Sun, May 20, 2012 at 2:12 PM, Alvaro Herrera > <alvherre@commandprompt.com> 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
В списке pgsql-hackers по дате отправления: