Starting with 9.2, when a WAL segment is restored from the archive, it
is copied over any existing file in pg_xlog with the same name. This is
done in two steps: first the file is restored from archive to a
temporary file called RECOVERYXLOG, then the old file is deleted and the
temporary file is renamed in place. After that, a flag is set in shared
memory for each WAL sender, to tell them to close the old file if they
still have it open.
That doesn't work on Windows. As long as a walsender is keeping the old
file open, the unlink() on it fails. You get an error like this in the
startup process:
FATAL: could not rename file "pg_xlog/RECOVERYXLOG" to
"pg_xlog/00000001000000000000000D": Permission denied
Not sure how to fix that. Perhaps we could copy the data over the old
file, rather than unlink and rename it. Or signal the walsenders and
retry if the unlink() fails with EACCESS.
Now, another question is, do we need to delay the release because of
this? The impact of this is basically that cascading replication
sometimes causes the standby to die, if a WAL archive is used together
with streaming replication.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
