On Wed, Jan 22, 2014 at 9:48 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
