| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
| 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>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-04-21 15:41:49 |
| Message-ID: | 49EDE93D.80208@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andreas Pflug wrote:
> I'm a little confused. After pg_standby returned non-zero as indication
> for end-of-recovery, the startup process shouldn't request another file
> from pg_standby, right?
Non-zero return value from restore_command doesn't mean end-of-recovery,
it means file-not-found. The server will try to open the WAL file from
pg_xlog if it's not found in archive (= restore_command returned
non-zero). If it's found in pg_xlog, it will then ask for the next WAL
file from the archive again. And on top of that, the server will ask for
history files until it finds one that doesn't exist to figure out the
new timeline.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2009-04-21 15:42:11 | Re: License Issue |
| Previous Message | Robert Haas | 2009-04-21 15:39:37 | Re: Automating Partitions in PostgreSQL - Query on syntax |