Re: Minor bug/inconveniance with restore from backup, using PITR base backup and archived wal files
От | Tom Lane |
---|---|
Тема | Re: Minor bug/inconveniance with restore from backup, using PITR base backup and archived wal files |
Дата | |
Msg-id | 4274.1222345154@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Minor bug/inconveniance with restore from backup, using PITR base backup and archived wal files (Tommy Gildseth <tommy.gildseth@usit.uio.no>) |
Ответы |
Re: Minor bug/inconveniance with restore from backup, using
PITR base backup and archived wal files
|
Список | pgsql-general |
Tommy Gildseth <tommy.gildseth@usit.uio.no> writes: > ... problem came at the end of the recovery, after the log line: > [2008-09-23 15:33:14.764 CEST] [pgtest01] [:] [] [18393] [] LOG: archive > recovery complete > followed immediately after by this line: > [2008-09-24 13:04:52.168 CEST] pgtest01] [:] [] [13324] [] PANIC: > could not open file "pg_xlog/00000002000000030000009F" (log file 3, > segment 159): Permission denied > and, the cluster shutting down. > 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. regards, tom lane
В списке pgsql-general по дате отправления: