| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, DimitriFontaine <dfontaine(at)hi-media(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: recovery.conf location |
| Date: | 2010-10-01 21:00:11 |
| Message-ID: | 4CA64BDB.1000500@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10/1/10 4:05 AM, Robert Haas wrote:
>>> And
>>> >> have PG poll that text file periodically so that you could update it and
>>> >> it would fail over?
>> >
>> > Hmm.. instead of that text file (i.e., recovery.conf), trigger file is
>> > periodically polled by the standby server.
>
> I'm not sure I understand the point of moving all the parameters except one.
Instead of having a setting which indicates a trigger file, and also
having a recovery.conf file (which is awkward at best) we would:
recovery.conf:
server_status = standby | active
Then instead of having a trigger file, the admin could just update the
status file in recovery.conf and save it (or overwrite the file). This
would also give admins an easy place to check what the current server
status is.
Our current arrangement of having a postgresql.conf file, a
recovery.conf file, and potentially a trigger file (during final
recovery) seems horribly hackish and impossible to manage neatly.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-10-01 21:20:22 | Re: recovery.conf location |
| Previous Message | Robert Haas | 2010-10-01 19:46:32 | Re: patch: tsearch - some memory diet |