On Wed, Jan 22, 2014 at 9:48 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-01-18 08:35:47 -0500, Robert Haas wrote:
>> > I am not sure I understand that point. We can either update the
>> > in-memory bit before performing the on-disk operations or
>> > afterwards. Either way, there's a way to be inconsistent if the disk
>> > operation fails somewhere inbetween (it might fail but still have
>> > deleted the file/directory!). The normal way to handle that in other
>> > places is PANICing when we don't know so we recover from the on-disk
>> > state.
>> > I really don't see the problem here? Code doesn't get more robust by
>> > doing s/PANIC/ERROR/, rather the contrary. It takes extra smarts to only
>> > ERROR, often that's not warranted.
>>
>> People get cranky when the database PANICs because of a filesystem
>> failure. We should avoid that, especially when it's trivial to do so.
>> The update to shared memory should be done second and should be set
>> up to be no-fail.
>
> I don't see how that would help. If we fail during unlink/rmdir, we
> don't really know at which point we failed.
This doesn't make sense to me. unlink/rmdir are atomic operations.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company