From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Fujii Masao <masao.fujii@gmail.com>
Cc: Guillaume Smet <guillaume.smet@gmail.com>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: New trigger option of pg_standby
Date: Wed, 13 May 2009 18:58:43 +0100
Message-ID: <1242237523.3843.461.camel@ebony.2ndQuadrant> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: simon@2ndQuadrant.com, tgl@sss.pgh.pa.us, heikki.linnakangas@enterprisedb.com, masao.fujii@gmail.com, guillaume.smet@gmail.com, peter_e@gmx.net, Kevin.Grittner@wicourts.gov
Subject: Re: New trigger option of pg_standby
In-Reply-To: <1242237523.3843.461.camel@ebony.2ndQuadrant>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox