Tom Lane wrote:
Tommy Gildseth <[EMAIL PROTECTED]> writes:
After a bit of looking around, and with some help from the fine people
in #postgresql on freenode, I think I figured out what was going on.
The last wal archive file was 00000001000000030000009F, and after
finishing recovery, postgresql created the file 00000002000000030000009F
(ie. 00000002 instead of 00000001) in pg_xlog.
It's customary for PG to "create" new XLOG segments by recycling old
ones.
The wal-files were
archived read-only, and this file permission seemed to be carried over
to the new file created by postgresql in pg_xlog, causing the cluster to
fall over and die.
I would say that the bug is in your restore script: it should have made
sure that the files it copies into the xlog directory are given the
right ownership/permissions.
Well, the restore command(script) is simply copied from the suggestion
in the manual (restore_command = 'cp /path/to/my/archived/wal/files/%f
"%p"'). In my opinion, it's not very obvious that the last wal file
needs read/write permissions set, and it's certainly not documented
anywhere on
http://www.postgresql.org/docs/current/static/continuous-archiving.html
that I can see.
There's also the matter of the inconsistency that postgresql knows to
recycle *and* chmod the file if it's originally located in pg_xlog/
folder, but not if it's originally located in the wal files archive
folder. I guess it's more of a gotcha than a bug per se.
--
Tommy Gildseth
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
