Command to prune archive at restartpoints
in [PgSql]
|
Prev: Order of pg_stat_activity timestamp columns
Next: pgsql: Reset btpo.xact following recovery ofbtree delete page.
From: Heikki Linnakangas on 18 Mar 2010 05:19 Committed. 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 > http://archives.postgresql.org/pgsql-hackers/2010-02/msg01003.php, 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 EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 18 Mar 2010 05:43 On Wed, 2010-03-17 at 11:37 +0200, 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 > http://archives.postgresql.org/pgsql-hackers/2010-02/msg01003.php, among > other things. .... > Barring objections, I will commit this later today. Would it be better to call this "archive_cleanup_command"? That might help people understand the need for and the use of this parameter. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Greg Stark on 22 Mar 2010 11:58
On Thu, Mar 18, 2010 at 9:43 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Wed, 2010-03-17 at 11:37 +0200, 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. > > Would it be better to call this "archive_cleanup_command"? That might > help people understand the need for and the use of this parameter. This is bikeshedding but fwiw I like Simon's suggestion. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |