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

Tom Lane wrote:
> 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?

I considered that, but didn't bother since InstallXLogFileSegment will
throw an error anyway if the file is locked, and that's a more common
codepath.

On closer look, it looks like the code in InstallXLogFileSegment is
trying to check the return code from rename, and not throw an error if
it fails because the file is locked, but it doesn't seem to be working
properly. When I open a WAL file with a separate program, and then cycle
through enough segments to have the file recycled, I get this:

ERROR:  could not rename file "pg_xlog/0000000100000001000000A0" to
"pg_xlog/0000000100000001000000A9" (initialization of log file 1,
segment 169): No such file or directory

I noted that behavior in my previous mail on the thread on pgsql-bugs,
but it didn't strike me as serious then.

FWIW, the checkpoint is mostly complete at that point, all that's left
is non-critical cleanup. I admit it's still annoying.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com