Re: Segmentation fault occurs when the standby becomes primary, in SR
От | Heikki Linnakangas |
---|---|
Тема | Re: Segmentation fault occurs when the standby becomes primary, in SR |
Дата | |
Msg-id | 4B61E436.20709@enterprisedb.com обсуждение исходный текст |
Ответ на | Segmentation fault occurs when the standby becomes primary, in SR (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Re: Segmentation fault occurs when the standby becomes
primary, in SR
Re: Segmentation fault occurs when the standby becomes primary, in SR |
Список | pgsql-hackers |
Fujii Masao wrote: > When I created the trigger file to activate the standby server, > I got the segmentation fault: > > ... > The attached patch would fix the bug. Thanks, committed. (I kept the old comment, though, I liked it better) Now, whether we should even allow setting up a standby without restore_command is another question. It's *possible*, but you need to enable archiving in the master anyway to take an on-line backup, and you need the archive to catch up if the standby ever falls behind too much. 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. 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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: