Re: pg_retainxlog for inclusion in 9.3?

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_retainxlog for inclusion in 9.3?
Date: 2013-01-25 21:23:21
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 1/25/13 12:24 PM, Andres Freund wrote:
> On 2013-01-26 02:21:00 +0900, Fujii Masao wrote:
>> 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?

That makes sense.

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

Well, pg_retainxlog kind of handwaves around that. If you use it in the
default mode, it assumes that the pg_receivexlog entries in
pg_stat_replication are that state. And then it says, if you use other
kinds of clients, you need to keep track of that state yourself. But
that seems to assume that pg_receivexlog never disconnects (thus losing
its entries from pg_stat_replication). (pg_receivexlog is designed to
automatically reconnect on connection loss, so this possibility was
obviously thought about.)

So it seems to me this just doesn't work (this way).

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-01-25 21:27:18 Re: WAL_DEBUG logs spurious data
Previous Message Bruce Momjian 2013-01-25 21:16:52 Re: No, pg_size_pretty(numeric) was not such a hot idea