Heikki Linnakangas wrote:
> Andreas Pflug wrote:
>> I've been following the thread with growing lack of understanding why
>> this is so hardly discussed, and I went back to the documentation of
>> what the restore_command should do (
>> http://www.postgresql.org/docs/8.3/static/warm-standby.html )
>>
>> While the algorithm presented in the pseudocode isn't dealing too good
>> with a situation where the trigger is set while the restore_command is
>> sleeping (this should be handled better in a real implementation), the
>> code says
>>
>> "Restore all wal files. If no more wal files are present, stop restoring
>> if the trigger is set; otherwise wait for a new wal file".
>>
>> Since pg_standby is meant as implementation of restore_command, it has
>> to follow the directive stated above; *anything else is a bug*.
>> pg_standby currently does *not* obey this directive, and has that
>> documented, but a documented bug still is a bug.
>
> I think you're interpreting the chapter too strongly. The provided
> pseudo-code is just an example of a suitable restore_command, it
> doesn't say that pg_standby behaves exactly like that.
After reading that chapter, I assumed that pg_standby actually does work
like this, and skipped reading the pg_standby specific doc....
The pgsql doc tries hard to give best advice for common situations,
especially for integrity and safety issues. IMHO it's best to have the
warm-standby chapter as reference how things should work for typical
use-cases.
Regards,
Andreas