Fujii Masao wrote: > On Fri, Feb 12, 2010 at 10:10 PM, Heikki Linnakangas > <heikki.linnakan...@enterprisedb.com> wrote: >>> So I suggest that you have a new action that gets called after every >>> checkpoint to clear down the archive. It will remove all files from the >>> archive prior to %r. We can implement that as a sequence of unlink()s >>> from within the server, or we can just call a script to do it. I prefer >>> the latter approach. However we do it, we need something initiated by >>> the server to maintain the archive and stop it from overflowing. >> +1 > > If we leave executing the remove_command to the bgwriter, the restartpoint > might not happen unfortunately for a long time.
Are you thinking of a scenario where remove_command gets stuck, and prevents bgwriter from performing restartpoints while it's stuck? You have trouble if restore_command gets stuck like that as well, so I think we can require that the remove_command returns in a reasonable period of time, ie. in a few minutes. > To prevent that situation, the > archiver should execute the command, I think. Thought? The archiver isn't running in standby, so that's not going to work. And it's not connected to shared memory either, so it doesn't know what the latest restartpoint is. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers