From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Postgresql-General <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Warm-Standby using WAL archiving / Seperate pg_restorelog |
Date: | 2006-07-10 21:40:10 |
Message-ID: | 44B2C93A.1070106@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin Moncure wrote:
> On 7/10/06, Florian G. Pflug <fgp(at)phlo(dot)org> wrote:
>> This methods seems to work, but it is neither particularly fool-proof nor
>> administrator friendly. It's not possible e.g. to reboot the slave
>> without postgres
>> abortint the recovery, and therefor processing all wals generated
>> since the last
>> backup all over again.
>>
>> Monitoring this system is hard too, since there is no easy way to
>> detect errors
>> while restoring a particular wal.
>
> what I would really like to see is to have the postmaster start up in
> a special read only mode where it could auto-restore wal files placed
> there by an external process but not generate any of its own. This
> would be a step towards a pitr based simple replication method.
I didn't dare to ask for being able to actually _access_ a wal-shipping
based slaved (in read only mode) - from how I interpret the code, it's
a _long_ way to get that working. So I figured a stand-alone executable
that just recovers _one_ archived wal would at least remove that administrative
burden that my current solution brings. And it would be easy to monitor
the slave - much easier than with any automatic pickup of wals.
greetings, Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2006-07-10 21:48:18 | Re: lastval exposes information that currval does not |
Previous Message | Martijn van Oosterhout | 2006-07-10 21:35:54 | Re: CTIDs invalidations and dropping columns. |