Warm Standby restore_command documentation (was: New trigger option of pg_standby) - Mailing list pgsql-hackers

From Andreas Pflug
Subject Warm Standby restore_command documentation (was: New trigger option of pg_standby)
Date
Msg-id 49E4D643.3050707@pse-consulting.de
Whole thread Raw
In response to Re: New trigger option of pg_standby  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Warm Standby restore_command documentation (was: New trigger option of pg_standby)  (Fujii Masao <masao.fujii@gmail.com>)
Re: Warm Standby restore_command documentation  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
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.

Regards,
Andreas


pgsql-hackers by date:

Previous
From: - -
Date:
Subject: Re: Unicode support
Next
From: Peter Eisentraut
Date:
Subject: Re: Unicode string literals versus the world