Re: pg_stop_backup running for 10h?
| От | François Beausoleil |
|---|---|
| Тема | Re: pg_stop_backup running for 10h? |
| Дата | |
| Msg-id | 794BC5F5-F039-48A3-B769-778D43ABA825@teksol.info обсуждение исходный текст |
| Ответ на | Re: pg_stop_backup running for 10h? (Magnus Hagander <magnus@hagander.net>) |
| Список | pgsql-general |
Le 2014-01-12 à 05:38, Magnus Hagander a écrit :
On Sat, Jan 11, 2014 at 11:26 PM, François Beausoleil <francois@teksol.info> wrote:Hi all,I'm using OmniPITR to build a new slave. According to pg_stat_activity, pg_stop_backup has been running for nearly 11 hours. The WAL archive command is running just fine and reporting "Segment X successfully sent to all destinations".I had the same issue almost a year ago (http://www.postgresql.org/message-id/9CC57302-10F8-4678-BBD3-028EC6B57051@teksol.info), but don't have permission issues this time around.What could cause a pg_stop_backup() to run for such a long time?Can't speak for the OmniPITR specific parts, but typically the archive_command reacting strangely would cause pg_stop_backup() to wait.You include the logs from omniptr, but do you get anything in the *postgresql* logs? If it's the archive command it should clearly tell you that. It should also tell you if you can safely cancel the pg_stop_backup() command.
Oh well... pg_stop_backup() eventually finished by itself:
2014-01-12 05:57:06.174590 +0000 : 22722 : omnipitr-backup-master : LOG : Timer [SELECT pg_stop_backup()] took: 66049.684s
2014-01-12 05:57:06.296063 +0000 : 22722 : omnipitr-backup-master : LOG : pg_stop_backup('omnipitr') returned 2489/10004E78.
2014-01-12 05:57:06.409591 +0000 : 22722 : omnipitr-backup-master : LOG : Timer [Making data archive] took: 116525.818s
or 18 hours. That's long...
Postgres' logs themselves didn't have any mention of problems with the archive_command, so that's ruled out as well.
Thanks for taking the time to respond!
François
Вложения
В списке pgsql-general по дате отправления: