Re: Segmentation fault occurs when the standby becomes primary, in SR
От | Fujii Masao |
---|---|
Тема | Re: Segmentation fault occurs when the standby becomes primary, in SR |
Дата | |
Msg-id | 3f0b79eb1001282304n57251eaan258ea5d9e5ebf739@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Segmentation fault occurs when the standby becomes primary, in SR (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
On Fri, Jan 29, 2010 at 4:23 AM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > Thanks, committed. (I kept the old comment, though, I liked it better) Thanks! > Then again, if the database is small, maybe you don't mind taking a new > base backup if the standby falls behind. And you *can* take a base > backup with a dummy archive_command (ie. archive_command='/bin/true'), > if you trust that the WAL files stay in pg_xlog long enough for standby > to stream them from there. Yeah, this is one of the case that restore_command is not required for SR. > Perhaps we should require a restore_command. If you know what you're > doing, you can always use '/bin/false' as restore_command to hack around it. One of main aim of SR is an easy-to-setup. So I don't want to impose such a hacky setting of restore_command on users. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: