Re: New trigger option of pg_standby
От | Simon Riggs |
---|---|
Тема | Re: New trigger option of pg_standby |
Дата | |
Msg-id | 1242237523.3843.461.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: New trigger option of pg_standby (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: New trigger option of pg_standby
Re: New trigger option of pg_standby Re: New trigger option of pg_standby |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: