Re: [RFC] What should we do for reliable WAL archiving?
От | MauMau |
---|---|
Тема | Re: [RFC] What should we do for reliable WAL archiving? |
Дата | |
Msg-id | 4D837AAE66BA4BE980F13FC061E86FC1@maumau обсуждение исходный текст |
Ответ на | Re: [RFC] What should we do for reliable WAL archiving? (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [RFC] What should we do for reliable WAL archiving?
Re: [RFC] What should we do for reliable WAL archiving? |
Список | pgsql-hackers |
From: "Amit Kapila" <amit.kapila16@gmail.com> > How about using pg_receivexlog for archiving purpose? pg_receivexlog is good in that it does fsync(). But it seems difficult to use correctly, and I'm not sure if I can catch all WAL segments without any loss. pg_receivexlog must be started with postmaster and monitored with some measures. This won't be very easy at least on Windows. The pg_receivexlog reference page suggests another difficulty: Notes When using pg_receivexlog instead of archive_command, the server will continue to recycle transaction log files even if the backups are not properly archived, since there is no command that fails. This can be worked around by having an archive_command that fails when the file has not been properly archived yet, for example: archive_command = 'sleep 5 && test -f /mnt/server/archivedir/%f' This suggestion is not correct, because it only checks the existence of the file. What if the file size is less than 16MB? How can we check if the file is completely archived? Regards MauMau
В списке pgsql-hackers по дате отправления: