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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
