Cascading replication on Windows bug

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Cascading replication on Windows bug
Date: 2012-09-05 21:03:55
Message-ID: 5047BE3B.3070900@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-09-05 21:09:41 Re: Proof of concept: standalone backend with full FE/BE protocol
Previous Message Tom Lane 2012-09-05 21:03:51 Re: Proof of concept: standalone backend with full FE/BE protocol