Re: pgsql: On Windows, when a file is deleted and another process still has - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: On Windows, when a file is deleted and another process still has
Date
Msg-id 23883.1252594892@sss.pgh.pa.us
Whole thread Raw
In response to pgsql: On Windows, when a file is deleted and another process still has  (heikki@postgresql.org (Heikki Linnakangas))
Responses Re: pgsql: On Windows, when a file is deleted and another process still has  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-committers
heikki@postgresql.org (Heikki Linnakangas) writes:
> Fix that by renaming the file with ".deleted" extension before deleting it.
> Also check the return value of rename() and unlink(), so that if the removal
> fails for any reason (e.g another process is holding the file locked), we
> don't delete the .done file until the WAL file is really gone.

This patch seems to me to be a seriously bad idea.  It means that some
random process holding a file open will be able to cause checkpoints to
fail indefinitely.  Is it really necessary or advisable to have the
error cases be elog(ERROR)?  Couldn't we just elog(LOG) and leave the
file alone?

            regards, tom lane

pgsql-committers by date:

Previous
From: ishii@postgresql.org (Tatsuo Ishii)
Date:
Subject: pgsql: pgbench has #defines for number of branches, tellers, and
Next
From: alvherre@postgresql.org (Alvaro Herrera)
Date:
Subject: pgsql: Add note that the logging collector can block backends in high