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

Re: Command to prune archive at restartpoints

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Dimitri Fontaine <dfontaine(at)hi-media(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-10 19:49:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 10/06/10 22:24, Dimitri Fontaine wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com>  writes:
>> Maybe we could add a new pg_cleanuparchive binary, but we'll need some
>> discussion...
> Would this binary ever be used manually, not invoked by PostgreSQL? As
> it depends on the %r option to be given and to be right, I don't think
> so.

Hmm, actually it would be pretty handy. To make use of a base backup, 
you need all the WAL files following the one where pg_start_backup() was 
called. We create a .backup file in the archive to indicate that 
location, like:


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 /walarchive/ 00000001000000000000002F

Of course, if there's a perl one-liner to do that, we can just put that 
in the docs and don't really need pg_cleanuparchive at all.

> Therefore my take on this problem is to provide internal commands here,
> that maybe wouldn't need to be explicitly passed any argument. If
> they're internal they certainly can access to the information they need?

You want more flexibility in more advanced cases. Like if you have 
multiple standbys sharing the archive, you only want to remove old WAL 
files after they're not needed by *any* of the standbys anymore. Doing 
the cleanup directly in the archive_cleanup_command would cause the old 
WAL files to be removed prematurely, but you could put a shell script 
there to store the location to a file, and call pg_cleanuparchive with 
the max() of the locations reported by all standby servers.

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-06-10 20:09:05
Subject: Re: Command to prune archive at restartpoints
Previous:From: Dimitri FontaineDate: 2010-06-10 19:24:41
Subject: Re: Command to prune archive at restartpoints

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