Re: New trigger option of pg_standby

On Wed, 2009-05-13 at 13:01 -0400, Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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