Simon Riggs wrote:
> On Wed, 2008-12-10 at 14:51 +0900, Fujii Masao wrote:
>> For clarity: the user can choose the strategy of archiving from the
>> following.
>>
>> 1) each primary and standby archives
>> 2) only primary archives
>> 3) only standby archives
>> 4) no server archives
>
> Those are all possible, but they aren't all equally usable as it stands.
>
> In my experience most people do things very simply, so (4) is the common
> use case. So it needs to Just Work.
Agreed. All this talk about archiving and streaming working at the same
time is very confusing.
AFAICS, the patch as submitted doesn't work if archiving is disabled in
the primary. Which means that strategies (2) and (4) in your list are
not possible. The standby relies on the archiving and file-based log
shipping to work correctly. The streaming is just an extra thing,
shortcutting the normal file-based log shipping path to keep the latest
WAL segment up-to-date in the standby.
In the current form, is there any reason why walreceiver needs to be an
integrated server process? Couldn't it just be a stand-alone program
that connects to the primary and writes the received records to the
right WAL file? The only reason I can see is to reliably kill it when
the standby server is promoted to primary.
For a solution that doesn't depend on the file-based log shipping, I
think we'll need a way for the standby to request a certain starting
point for the streaming when it connects. When the standby starts, it
would first recover all the log segments it can obtain using
recovery_command, and then connect to the primary and request to start
streaming from where recovery_command stopped.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
