Subject: Re: New trigger option of pg_standby
From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	Fujii Masao <masao.fujii@gmail.com>,
	Guillaume Smet <guillaume.smet@gmail.com>,
	Peter Eisentraut <peter_e@gmx.net>,
	Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
In-Reply-To: <1985.1242234105@sss.pgh.pa.us>
References: <3f0b79eb0903242329j12865d55s348f5c873a956e71@mail.gmail.com>
	<1239381103.16396.30.camel@ebony.2ndQuadrant>
	<3f0b79eb0904122252t1f4c5860v919d199f399ccf72@mail.gmail.com>
	<3f0b79eb0904132241p18084914g792cb8e5ab3eebb3@mail.gmail.com>
	<3f0b79eb0904150101pb1c59a3ubb422867e8e6a944@mail.gmail.com>
	<49EE1E3F.9050307@enterprisedb.com>
	<3f0b79eb0904212209i7fbd8b68k71db1fef09c62751@mail.gmail.com>
	<49F01D79.8020805@enterprisedb.com>
	<3f0b79eb0904230515p751b5248n6ef96880617db055@mail.gmail.com>
	<4A095A39.3030100@enterprisedb.com>
	<3f0b79eb0905130127u3a3275b1w79f4d8cb729ded36@mail.gmail.com>
	<4A0A86D2.9080602@enterprisedb.com>  <1985.1242234105@sss.pgh.pa.us>
Content-Type: text/plain
Date: Wed, 13 May 2009 18:58:43 +0100
Message-Id: <1242237523.3843.461.camel@ebony.2ndQuadrant>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


On Wed, 2009-05-13 at 13:01 -0400, Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> > I don't think we're going to get this to work reliably without extending 
> > the interface between the backend and restore_command. We've discussed 
> > many methods and there's always some nasty corner-case like that.

Agreed.

> > I think we should leave back-branches as is, and go with Simon's 
> > suggestion to add new "recovery_end_command" that's run when the 
> > recovery is finished. That's simpler and more reliable than any of the 
> > other approaches we've discussed, and might become handy for other 
> > purposes as well.

That is the cleanest way, though we cannot really avoid acting for
backbranches also.

> > Does someone want to take a stab at writing a patch for that?

No, not if there is a likelihood the work would be wasted.

> Does this conclusion mean that changing pg_standby is no longer
> on the table for 8.4?  It certainly smells more like a new feature
> than a bug fix.

I don't really understand this comment. Why would fixing a memory leak
be worthwhile when fixing a potential for data loss be a deferrable
activity?


I will set-up pg_standby as an external module and we can change it from
there. No more discussions-for-8.4 and I can update as required to
support each release. So let's just remove it from contrib and be done.
Counterthoughts?

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