Re: Hot standby and synchronous replication status
От | Robert Haas |
---|---|
Тема | Re: Hot standby and synchronous replication status |
Дата | |
Msg-id | 603c8f070908111450r6bbec5aeqf5fadec15e29df6e@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hot standby and synchronous replication status (Dimitri Fontaine <dfontaine@hi-media.com>) |
Ответы |
Re: Hot standby and synchronous replication status
Re: Hot standby and synchronous replication status |
Список | pgsql-hackers |
On Tue, Aug 11, 2009 at 5:40 PM, Dimitri Fontaine<dfontaine@hi-media.com> wrote: > Le 11 août 09 à 23:30, Robert Haas a écrit : > >> On Tue, Aug 11, 2009 at 5:20 PM, Dimitri Fontaine<dfontaine@hi-media.com> >> wrote: >>> >>> We should somehow provide a default archive and restore command >>> integrated >>> into the main product, so that it's as easy as turning it 'on' in the >>> configuration for users to have something trustworthy: PostgreSQL will >>> keep >>> past logs into a pg_xlog/archives subdir or some other default place, and >>> will know about the setup at startup time when/if needed. >> >> I might be missing something, but isn't this completely silly? If you >> archive your logs to the same partition where you keep your database >> cluster, it seems to me that you might as well delete them. Even >> better, turn off XLogArchiving altogether and save yourself the >> overhead of not using WAL-bypass. > > Nice, the pushback is about the default location, thanks for supporting the > idea :) > > Seriously, debian package will install pg_xlog in $PGDATA which is often not > what I want. So first thing after install, I stop the cluster, move the > pg_xlog, setup a ln -s and restart. I figured having to do the same for > setting up archiving would make my day, when compared to current > documentation setup. Any better idea for a safe enough default location is > welcome, of course. *scratches head* I don't really know how you COULD pick a safe default location. Presumably any location that's in the default postgresql.conf file would be under $PGDATA, which kind of defeats the purpose of the whole thing. In other words, you're always going to have to move it anyway, so why bother with a default that is bound to be wrong? Maybe I'm all wet? ...Robert
В списке pgsql-hackers по дате отправления: