Re: Interaction of PITR backups and Bulkoperationsavoiding WAL
От | Simon Riggs |
---|---|
Тема | Re: Interaction of PITR backups and Bulkoperationsavoiding WAL |
Дата | |
Msg-id | 1173459439.3641.291.camel@silverbirch.site обсуждение исходный текст |
Ответ на | Re: Interaction of PITR backups and Bulk operationsavoiding WAL (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Interaction of PITR backups and Bulkoperationsavoiding WAL
Re: Interaction of PITR backups and Bulkoperationsavoiding WAL Re: Interaction of PITR backups and Bulkoperationsavoiding WAL Re: Interaction of PITR backups and Bulkoperationsavoiding WAL Re: Interaction of PITR backups and Bulkoperationsavoiding WAL |
Список | pgsql-hackers |
On Fri, 2007-03-09 at 11:47 -0500, Tom Lane wrote: > "Simon Riggs" <simon@2ndquadrant.com> writes: > > On Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote: > >> It strikes me that allowing archive_command to be changed on the fly > >> might not be such a good idea though, or at least it shouldn't be > >> possible to flip it from empty to nonempty during live operation. > > > I'd rather fix it the proposed way than force a restart. ISTM wrong to > > have an availability feature cause downtime. > > I don't think that people are very likely to need to turn archiving on > and off on-the-fly. Your proposed solution introduces a great deal of > complexity (and risk of future bugs-of-omission, to say nothing of race > conditions) to solve a non-problem. We have better things to be doing > with our development time. It's certainly a quicker fix. Unless others object, I'll set archive_command to only be changeable at server startup. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: