Cascading replication on Windows bug

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Cascading replication on Windows bug
Дата
Msg-id 5047BE3B.3070900@iki.fi
обсуждение исходный текст
Ответы Re: Cascading replication on Windows bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Proof of concept: standalone backend with full FE/BE protocol
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Proof of concept: standalone backend with full FE/BE protocol