Skip site navigation (1) Skip section navigation (2)

Re: Incomplete docs for restore_command for hot standby

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Markus Bertheau <mbertheau(dot)pg(at)googlemail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Incomplete docs for restore_command for hot standby
Date: 2008-02-21 21:18:32
Message-ID: 1203628712.4229.53.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-patches
On Thu, 2008-02-21 at 08:01 +0600, Markus Bertheau wrote:
> (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.

The two sentences aren't mutually exclusive, especially when you
consider they are discussing two different use cases. Why not read up on
pg_standby anyway?

> 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).

Old email written during beta. Read at your own peril.

> 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.

If you have some suggested changes, I'd be happy to hear them.

Probably additions are better than just changes though.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com 


In response to

Responses

pgsql-bugs by date

Next:From: David LeeDate: 2008-02-21 23:34:12
Subject: BUG #3979: SELECT DISTINCT slow even on indexed column
Previous:From: Vincent D'HaeneDate: 2008-02-21 20:53:42
Subject: Re: BUG #3951: SELECT ... WHERE Param = ? does not work if Param is of type bytea

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2008-02-21 21:21:21
Subject: Re: fix in --help output
Previous:From: Zdenek KotalaDate: 2008-02-21 21:16:15
Subject: Re: fix in --help output

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group