Hi, On Wed, Apr 15, 2009 at 3:30 AM, Andreas Pflug <pgad...@pse-consulting.de> 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. > > Conclusion: There's no "new trigger option" needed, instead pg_standby > has to be fixed so it does what the warm standby option of postgres > needs. The trigger is only to be examined if no more files are > restorable, and only once.
Yeah, as a result of the discussion on that thread, I'll change the default behavior instead of adding new trigger option. But, I'm not going to get rid of the current behavior; it's chosen if the trigger file containing "fast" exists. On the other hand, new behavior is chosen when the trigger file containing "smart" or an empty one exists (default). Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
