From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Warm Standby restore_command documentation |
Date: | 2009-04-20 08:32:23 |
Message-ID: | 49EC3317.7090209@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2009-04-20 09:06:09 | Re: New trigger option of pg_standby |
Previous Message | Pavel Stehule | 2009-04-20 06:52:05 | Re: Patch for 8.5, transformationHook |