Hi,
On Wed, Apr 15, 2009 at 3:30 AM, 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.
>
> 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
