Skip site navigation (1) Skip section navigation (2)

Re: Command to prune archive at restartpoints

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Command to prune archive at restartpoints
Date: 2010-06-12 18:00:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> So to clean up all WAL files older than those needed by that base backup,
>> you would simply copy-paste that location and call pg_cleanuparchive:
>> pg_cleanuparchive /walarchive/ 00000001000000000000002F
> Ok, idle though: what about having a superuser-only SRF doing the
> same?

So I'm looking at what it'd take to have that code, and it seems it
would be quite easy. I wonder if we want to return only a boolean
(command success status) or the list of files we're pruning (that's the
SRF part), but other than that, it's all about having the code provided
by Simon in another place and some internal command support.

Something strange though: I notice that the error and signal handling in
pgarch.c::pgarch_archiveXlog (lines 551 and following) and in
xlog.c::ExecuteRecoveryCommand (lines 3143 and following) are very
different for no reason that I can see.

Why is that?

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


In response to


pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2010-06-12 20:51:48
Subject: Re: Command to prune archive at restartpoints
Previous:From: David E. WheelerDate: 2010-06-12 17:32:30
Subject: Re: hstore ==> and deprecate =>

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group