| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: New trigger option of pg_standby |
| Date: | 2009-05-13 17:01:45 |
| Message-ID: | 1985.1242234105@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
> 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.
> Does someone want to take a stab at writing a patch for that?
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2009-05-13 17:58:43 | Re: New trigger option of pg_standby |
| Previous Message | Tom Lane | 2009-05-13 16:52:20 | Re: pg_views definition format |