Re: Architecture of walreceiver (Streaming Replication)

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Architecture of walreceiver (Streaming Replication)
Date: 2009-11-02 18:28:01
Message-ID: 4AEF24B1.4090604@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Euler Taveira de Oliveira wrote:
> Fujii Masao escreveu:
>> IMO, walreceiver should be a subprocess of postmaster for
>> the following reasons.
>>
> +1. I agree that the first version should be as close as possible to
> postmaster. My points are: (i) it will be easier to install (no need to
> install another third-party software), (ii) it will be easier to administrate
> (the options will be available in one central point -- postgresql.conf), and
> (iii) it will be easier to control (it is a postmaster subprocess).

None of these points are really for or against either approach. In any
case, we would ship with all the required components, so no need to
install 3rd party software. The recovery related options would come from
recovery.conf in both models, although that could be changed if we
wanted to.

Not sure what easier to control (iii) means, although admittedly it's a
bit tricky to make it walreceiver behave correctly as a subprocess of
the startup process, making sure it responds to shutdown requests etc.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-11-02 18:28:09 Re: operator exclusion constraints
Previous Message Heikki Linnakangas 2009-11-02 18:23:15 Re: Architecture of walreceiver (Streaming Replication)