Re: New trigger option of pg_standby

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New trigger option of pg_standby
Date: 2009-05-13 20:43:24
Message-ID: 1242247404.3843.503.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:

> This whole thing can be considered to be a new feature.

recovery.conf will contain a new optional parameter:

recovery_end_command (string)

This parameter specifies a shell command that will be executed once only
at the end of recovery. This parameter is optional. The purpose of the
recovery_end_command is to provide a mechanism for cleanup following
replication or recovery. Any %r is replaced by the name of the file
containing the last valid restart point. That is the earliest file that
must be kept to allow a restore to be restartable, so this information
can be used to truncate the archive to just the minimum required to
support restart of the current restore. %r would only be used in a
warm-standby configuration (see Section 24.4). Write %% to embed an
actual % character in the command.

recovery_end_command is performed *after* the UpdateControlFile() once
the we are DB_IN_PRODUCTION.

This behaviour ensures that a crash prior to the final checkpoint will
continue to see the trigger file. Once we are safe, we can remove the
trigger file safely. We also can now ignore any complexity surrounding
whether WAL files are full or not, and whether WAL files were restored
from the archive or from the local directory.

Comments?

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-05-13 20:47:26 Re: New trigger option of pg_standby
Previous Message Simon Riggs 2009-05-13 20:42:20 Re: New trigger option of pg_standby