Re: Command to prune archive at restartpoints

On Sat, Jun 12, 2010 at 4:51 PM, Dimitri Fontaine
<dfontaine(at)hi-media(dot)com> wrote:
> Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
>> Also, should I try to send a patch implementing my proposal (internal
>> command exposed as a function at the SQL level, and while at it, maybe
>> the internal command "pg_archive_bypass" to mimic /usr/bin/true as an
>> archive_command)?
>
> I had to have a try at it, even if quick and dirty. I've not tried to
> code the pg_archive_bypass internal command for lack of discussion, but
> I still think it would be great to have it.
>
> So here's a "see my idea in code" patch, that put the previous code by
> Simon into a backend function. As the goal was not to adapt the existing
> code intended as external to use the internal APIs, you'll find it quite
> ugly I'm sure.
>
> For example, this #define XLOG_DATA_FNAME_LEN has to go away, but that
> won't help having the idea accepted or not, and as I'm only warming up,
> I didn't tackle the problem. If you want me to do it, I'd appreciate
> some guidance as how to, though.
>
> It goes like this:
>
> dim=# select pg_switch_xlog();
>  pg_switch_xlog
> ----------------
>  0/1000098
> (1 row)
>
> dim=# select pg_archive_cleanup('0/1000098');
> DEBUG:  removing "pg_xlog/000000010000000000000000"
> DEBUG:  removing "pg_xlog/000000010000000000000001"
>  pg_archive_cleanup
> --------------------
>  t
> (1 row)
>
> I hope you too will find this way of interfacing is easier to deal with
> for everybody (from code maintenance to user settings).

I'm a bit perplexed here. The archive cleanup has to run on the
standby, not the master, right? Whereas pg_switch_xlog() can only run
on the master. The purpose of making this a standalone executable is
so that people who have, for example, multiple standbys, can customize
the logic without having to hack the backend. Pushing this into the
backend would defeat that goal; plus, it wouldn't be usable at all for
people who aren't running Hot Standby.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company