Re: pg_retainxlog for inclusion in 9.3?

On 2013-01-26 02:21:00 +0900, Fujii Masao wrote:
> On Sat, Jan 5, 2013 at 11:11 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> > On Fri, Jan 4, 2013 at 7:13 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> >> On 1/3/13 12:30 PM, Robert Haas wrote:
> >>> On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> >>>> Any particular reason? It goes pretty tightly together with
> >>>> pg_receivexlog, which is why I'd prefer putting it alongside that one.
> >>>> But if you have a good argument against it, I can change my mind :)
> >>>
> >>> Mostly that it seems like a hack, and I suspect we may come up with a
> >>> better way to do this in the future.
> >>
> >> It does seem like a hack. Couldn't this be implemented with a backend
> >> switch instead?
> >
> > It definitely is a bit of a hack.
> >
> > I assume by backend switch you mean guc, right? If so, no, not easily
> > so. Because it's the archiver process that does the deleting.
>
> The process which deletes the old WAL files is the checkpointer. The
> checkpointer can access to the shared memory and know the location
> of the WAL record which has been already replicated to the standby.
> ISTM it's not difficult to implement the logic which pg_retainxlog provides
> into the checkpointer. How about just changing the checkpointer so
> that it checks whether the WAL file to delete has been already not
> only archived but also replicated if GUC flag is enabled?

The problem with that is that to implement it robustly we would need
persistent state about the replicas.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services