Re: postgresql.conf archive_command example
От | Andres Freund |
---|---|
Тема | Re: postgresql.conf archive_command example |
Дата | |
Msg-id | 201109101029.27316.andres@anarazel.de обсуждение исходный текст |
Ответ на | Re: postgresql.conf archive_command example (Florian Pflug <fgp@phlo.org>) |
Список | pgsql-hackers |
On Friday, September 09, 2011 08:59:43 PM Florian Pflug wrote: > On Sep8, 2011, at 15:09 , Aidan Van Dyk wrote: > > Personally, I think both of these show examples of why PG should be > > looking hard at either providing a simple robust local directory based > > archive_command, or very seriously pointing users at properly written > > tools like omniptr, or ptrtools, walmgr, etc... > > > > Neither of those cases should ever happen. If you're copying a file > > into the archive, and making it appear non-atomically in your archive, > > your doing something wrong. > > +1000. > > Archiving WAL should be done by copying to a temp file and moving it > into place. Before returning success, one should probably also do the > fsync incantations the linux kernel guys argued are necessary to prevent > the file from appearing empty if the machine crashes shortly after the > move. (Yeah, they fixed that after enough people complained, but the fact > that they even went as far as arguing their behaviour is correct according > to POSIX makes me uneasy...) The only problem being that its only fixed with certain mount options on a certain filesystem (ext3, ext4, data=ordered). Every other filesystem (like e.g. XFS) still does it that way. And did it for at least a decade. It makes me just as uneasy that so few people knew about that - preexisting! - problem... > It'd be very cool if we shipped a tool that did that correctly (pg_walcopy > maybe?) on all supported platforms. +1
В списке pgsql-hackers по дате отправления: