Cascading replication on Windows bug - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Cascading replication on Windows bug
Date
Msg-id 5047BE3B.3070900@iki.fi
Whole thread Raw
Responses Re: Cascading replication on Windows bug  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Next
From: Bruce Momjian
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol