From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL |
Date: | 2010-02-12 16:10:05 |
Message-ID: | 4B757D5D.3070506@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-docs pgsql-hackers |
Fujii Masao wrote:
> On Fri, Feb 12, 2010 at 10:10 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2010-02-12 17:25:02 | Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL |
Previous Message | Fujii Masao | 2010-02-12 15:47:42 | Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL |
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2010-02-12 16:15:03 | Re: Confusing link in streaming replication section |
Previous Message | Fujii Masao | 2010-02-12 15:47:42 | Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-02-12 16:55:40 | Re: review: More frame options in window functions |
Previous Message | Marko Kreen | 2010-02-12 15:50:30 | Re: TCP keepalive support for libpq |