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.comPostgreSQL Training, Services and Support
