Re: Warm Standby restore_command documentation - Mailing list pgsql-hackers

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

I agree we should change the default behavior, though.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [GENERAL] Performance of full outer join in 8.3
Next
From: Heikki Linnakangas
Date:
Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE