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

Re: Dividing progress/debug information in pg_standby, and stat before copy

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com>, Selena Deckelmann <selenamarie(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndQuadrant(dot)com>
Subject: Re: Dividing progress/debug information in pg_standby, and stat before copy
Date: 2010-01-26 18:53:48
Message-ID: 4B5F3A3C.7090604@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 1/26/10 10:48 AM, Heikki Linnakangas wrote:
> Josh Berkus wrote:
>>> *That* makes pg_standby obsolete, not streaming replication per se.
>>> Setting standby_mode=on, with a valid restore_command using e.g 'cp' and
>>> no connection info for walreceiver is more or less the same as using
>>> pg_standby.
>> What about deletion of no-longer-needed WALfile copies?
> 
> Yeah, good point. You can still use a shell script as restore_command,
> pass the %r option to it, and do the deletion there.
> 
> I didn't intend to replace pg_standby when I started this, it just kind
> of happened. Maybe we should provide a sample script similar to
> pg_standby, to be used instead of plain 'cp', that does the cleanup too.

What I'm pointing out is that you haven't *quite* replaced pg_standby,
and at this late date aren't going to.  Some people will still want to
use it.  Especially for people who for some reason aren't using SR.

--Josh Berkus


In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-01-26 18:56:44
Subject: Re: About "Our CLUSTER implementation is pessimal" patch
Previous:From: Heikki LinnakangasDate: 2010-01-26 18:48:52
Subject: Re: Dividing progress/debug information in pg_standby, and stat before copy

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