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: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Command to prune archive at restartpoints
Date: 2010-03-18 09:19:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Heikki Linnakangas wrote:
> One awkward omission in the new built-in standby mode, mainly used for
> streaming replication, is that there is no easy way to delete old
> archived files like you do with the %r parameter to restore_command.
> This was discussed at
>, among
> other things.
> Per discussion, attached patch adds a new restartpoint_command option to
> recovery.conf. That's an external shell command just like
> recovery_end_command that's executed at every restartpoint. You can use
> the %r parameter to pass the filename of the oldest WAL file that needs
> to be retained.
> While developing this I noticed that %r in recovery_end_command is not
> working correctly:
> LOG:  redo done at 0/14000C10
> LOG:  last completed transaction was at log time 2000-01-01
> 02:21:08.816445+02
> cp: cannot stat
> `/home/hlinnaka/pgsql.cvshead/walarchive/000000010000000000000014': No
> such file or directory
> cp: cannot stat
> `/home/hlinnaka/pgsql.cvshead/walarchive/00000002.history': No such file
> or directory
> LOG:  selected new timeline ID: 2
> cp: cannot stat
> `/home/hlinnaka/pgsql.cvshead/walarchive/00000001.history': No such file
> or directory
> LOG:  archive recovery complete
> LOG:  checkpoint starting: end-of-recovery immediate wait
> LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 transaction log
> file(s) added, 0 removed, 0 recycled; write=0.000 s, sync=0.000 s,
> total=0.003 s
> LOG:  executing recovery_end_command "echo recovery_end_command %r"
> recovery_end_command 000000000000000000000000
> LOG:  database system is ready to accept connections
> LOG:  autovacuum launcher started
> Note how %r is always expanded to 000000000000000000000000. That's
> because %r is expanded only when InRedo is true, which makes sense for
> restore_command where that piece of code was copy-pasted from, but it's
> never true anymore when recovery_end_command is run. The attached patch
> fixes that too.
> Barring objections, I will commit this later today.

  Heikki Linnakangas

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-03-18 09:43:24
Subject: Re: Command to prune archive at restartpoints
Previous:From: Gokulakannan SomasundaramDate: 2010-03-18 08:59:23
Subject: Re: An idle thought

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