On Wed, 2009-05-13 at 13:01 -0400, Tom Lane wrote: > Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
