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

Re: [HACKERS] Hot Standby utility and administrator functions

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Hot Standby utility and administrator functions
Date: 2008-10-23 17:16:26
Message-ID: 1224782186.27145.650.camel@ebony.2ndQuadrant (view raw or flat)
Thread:
Lists: pgadmin-hackerspgsql-generalpgsql-hackers
Could I get some input on the control functions that might be needed for
Hot Standby please? Think adminpack-for-HotStandby. Thanks.

What operations in pgAdmin would fail if we connected using a (forced)
read only transaction? Will they be disabled, or will they just throw
errors?

------------------------------------------------------------------------

On Mon, 2008-10-20 at 10:25 +0100, Simon Riggs wrote:
> I'm looking to implement the following functions for Hot Standby, to
> allow those with administrative tools or management applications to have
> more control during recovery. Please let me know if other functions are
> required.
> 
> What else do we need?
> 
> * pg_is_in_recovery()
> returns bool (true if in recovery, false if not)
> 
> * pg_last_recovered_xact_xid()
> Will throw an ERROR if *not* executed in recovery mode.
> returns bigint 
> 
> * pg_last_completed_xact_xid()
> Will throw an ERROR *if* executed in recovery mode.
> returns bigint 
> 
> (together allows easy arithmetic on xid difference between master and
> slave).
> 
> * pg_last_recovered_xact_timestamp()
> returns timestamp with timezone
> (allows easy arithmetic with now() to allow derivation of replication
> delay etc)
> 
> * pg_freeze_recovery() - freezes recovery after the current record has
> been applied. The server is still up and queries can happen, but no WAL
> replay will occur. This is a temporary state change and we keep no
> record of this, other than making a server log entry. If the server is
> shutdown or crashes, it will unfreeze itself automatically. Has no
> effect on master.
> Will throw an ERROR if not executed in recovery mode.
> Superusers only.
> returns text (XLogRecPtr of freeze point)
> 
> * pg_unfreeze_recovery() - unfreezes recovery. Recovery will begin again
> at exactly the point recovery was frozen at.
> Will throw an ERROR is not executed in recovery mode.
> Superusers only.
> returns bool (true if unfroze, false if was not frozen when called)
> 
> * pg_end_recovery() - 
> Will force recovery to end at current location. Recovery mode cannot be
> easily re-entered, so there is no "restart" function.
> Will throw an ERROR is not executed in recovery mode.
> Superusers only.
> returns text (XLogRecPtr of freeze point)
> 
> * pg_start_backup()/pg_stop_backup() could work during recovery, but the
> backup history file would need to be manually inserted into the archive
> once complete. Is that acceptable? (Note that we don't know where the
> archive is or how to access that; the information is all in
> recovery_command. We cannot assume that archive_command points to same
> archive. So making it happen automatically is too much work for this
> release, if ever.) If that seems useful, we could do this by avoiding
> any operation that changes WAL stream during recovery: no checkpoints,
> log switches etc.. 
> pg_start_backup() would return XLogRecPtr of last restartpoint.
> pg_stop_backup() would return last known xlrec recovered (we won't keep
> track of this record by record).
> 
> * pg_reload_conf() will not force re-read of recovery.conf since that
> may require extra work and doesn't seem that important, if we have the
> manual override mentioned above.
> 
> All desirable? All possible? Any others?

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


In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2008-10-23 17:24:11
Subject: Re: Block level concurrency during recovery
Previous:From: Simon RiggsDate: 2008-10-23 17:11:24
Subject: Re: [HACKERS] Hot Standby utility and administrator functions

pgadmin-hackers by date

Next:From: Guillaume LelargeDate: 2008-10-23 18:17:46
Subject: Patch for Index stat
Previous:From: Simon RiggsDate: 2008-10-23 17:11:24
Subject: Re: [HACKERS] Hot Standby utility and administrator functions

pgsql-general by date

Next:From: cywDate: 2008-10-23 17:19:55
Subject: Tips on how to efficiently debugging PL/PGSQL
Previous:From: Jack OrensteinDate: 2008-10-23 17:15:57
Subject: Re: Postgres optimizer choosing wrong index

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