From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | bricklen <bricklen(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Archiver not picking up changes to archive_command |
Date: | 2010-05-11 00:50:53 |
Message-ID: | 21571.1273539053@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
bricklen <bricklen(at)gmail(dot)com> writes:
> Due to some heavy processing today, we have been falling behind on
> shipping log files (by about a 1000 logs or so), so wanted to up our
> bwlimit like so:
> rsync -a %p postgres(at)192(dot)168(dot)80(dot)174:/WAL_Archive/ && rsync
> --bwlimit=1875 -az %p postgres(at)14(dot)121(dot)70(dot)98:/WAL_Archive/
> The db is showing the change.
> SHOW archive_command:
> rsync -a %p postgres(at)192(dot)168(dot)80(dot)174:/WAL_Archive/ && rsync
> --bwlimit=1875 -az %p postgres(at)14(dot)121(dot)70(dot)98:/WAL_Archive/
> Yet, the running processes never get above the original bwlimit of
> 1250. Have I missed a step? Would "kill -HUP <archiver pid>" help?
> (I'm leery of trying that untested though)
A look at the code shows that the archiver only notices SIGHUP once
per outer loop, so the change would only take effect once you catch up,
which is not going to help much in this case. Possibly we should change
it to check for SIGHUP after each archive_command execution.
If you kill -9 the archiver process, the postmaster will just start
a new one, but realize that that would result in two concurrent
rsync's. It might work ok to kill -9 the archiver and the current
rsync in the same command.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Christensen | 2010-05-11 01:04:05 | Re: peer-to-peer replication with Postgres |
Previous Message | bricklen | 2010-05-11 00:04:53 | Re: Archiver not picking up changes to archive_command |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-05-11 01:04:29 | Re: no universally correct setting for fsync |
Previous Message | Josh Berkus | 2010-05-11 00:26:54 | Re: no universally correct setting for fsync |