Just having a standby mode that survived shutdown/startup would be a nice
start...
I also do the blocking-restore-command technique, which although workable,
has a bit of a house-of-cards feel to it sometimes.
On 7/10/06 5:40 PM, "Florian G. Pflug" <[EMAIL PROTECTED]> wrote:
> Merlin Moncure wrote:
>> On 7/10/06, Florian G. Pflug <[EMAIL PROTECTED]> 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 Y&
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
