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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: On Windows, when a file is deleted and another process still has
Date: 2009-09-10 15:01:32
Message-ID: 23883.1252594892@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

heikki(at)postgresql(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2009-09-10 15:02:46 pgsql: Add note that the logging collector can block backends in high
Previous Message Tatsuo Ishii 2009-09-10 13:59:57 pgsql: pgbench has #defines for number of branches, tellers, and

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-09-10 15:06:19 Re: Disable and enable of table and column constraints
Previous Message Tom Lane 2009-09-10 14:44:22 Re: logging hook for database audit