From: | "Markus Bertheau" <mbertheau(dot)pg(at)googlemail(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Incomplete docs for restore_command for hot standby |
Date: | 2008-02-21 02:01:39 |
Message-ID: | 684362e10802201801hed3078ard2c6d1f81123d599@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-patches |
(I sent this to -docs already, but it didn't get through for some reason.)
From the current 8.3 docs:
Section 24.3.3.1 states about restore_command:
"The command will be asked for file names that are not present in the
archive; it must return nonzero when so asked."
Section 24.4.1 further states:
"The magic that makes the two loosely coupled servers work together is
simply a restore_command used on the standby that waits for the next
WAL file to become available from the primary."
It is not clear from the first paragraph, whether the non-existing
file that restore_command is being asked for is a not-yet-generated
WAL file or something different. If it was a not-yet-generated WAL
file, restore_command for replication would have to wait for it to
appear. If it was something different, restore_command for replication
would have to return an error right away. (Because else it would hang
indefinitely, waiting for a file that is not going to appear). Yet I
couldn't find hints in the documentation as to how these two cases can
be detected by restore_command, i.e. how restore_command should tell a
request for a WAL file from a request for a non-WAL file.
Practice (http://archives.postgresql.org/sydpug/2006-10/msg00001.php)
shows that this is a problem, and people use unproved heuristics
('history' substring in the requested file name).
Additionally, 24.3.3 contains slightly misleading information:
"It is important that the command return nonzero exit status on
failure. The command will be asked for log files that are not present
in the archive; it must return nonzero when so asked. This is not an
error condition."
This suggests that all non-existing files that restore_command will be
asked for are log files. One could therefore reasonably assume that
restore_command for replication should wait on all non-existing files.
24.3.3.1 later corrects this by stating that not only log files may be
requested, but nevertheless.
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Edwin Groothuis | 2008-02-21 07:16:53 | BUG #3975: tsearch2 index should not bomb out of 1Mb limit |
Previous Message | Tom Lane | 2008-02-20 22:55:06 | Re: BUG #3973: pg_dump using inherited tables do not always restore |
From | Date | Subject | |
---|---|---|---|
Next Message | Edwin Groothuis | 2008-02-21 07:16:53 | BUG #3975: tsearch2 index should not bomb out of 1Mb limit |
Previous Message | Stephen Davies | 2008-02-21 00:19:48 | ts_headline |