Re: Synchronous replication - patch status inquiry

From: David Fetter <david(at)fetter(dot)org>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, fazool mein <fazoolmein(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, ganesh(at)vmware(dot)com
Subject: Re: Synchronous replication - patch status inquiry
Date: 2010-09-14 21:38:17
Message-ID: 20100914213817.GD30314@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 10, 2010 at 11:52:20AM +0900, Fujii Masao wrote:
> On Fri, Sep 3, 2010 at 3:42 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> > Here is the proposed detailed design:
> >
> > standbys.conf
> > =============
> > # This is not initialized by initdb, so users need to create it under $PGDATA.
> >    * The template is located in the PREFIX/share directory.
> >
> > # This is read by postmaster at the startup as well as pg_hba.conf is.
> >    * In EXEC_BACKEND environement, each walsender must read it at the startup.
> >    * This is ignored when max_wal_senders is zero.
> >    * FATAL is emitted when standbys.conf doesn't exist even if max_wal_senders
> >      is positive.
> >
> > # SIGHUP makes only postmaser re-read the standbys.conf.
> >    * New configuration doesn't affect the existing connections to the standbys,
> >      i.e., it's used only for subsequent connections.
> >    * XXX: Should the existing connections react to new configuration? What if
> >      new standbys.conf doesn't have the standby_name of the existing
> > connection?
> >
> > # The connection from the standby is rejected if its standby_name is not listed
> >  in standbys.conf.
> >    * Multiple standbys with the same name are allowed.
> >
> > # The valid values of SYNCHRONOUS field are async, recv, fsync and replay.
> >
> > standby_name
> > ============
> > # This is new string-typed parameter in recovery.conf.
> >    * XXX: Should standby_name and standby_mode be merged?
> >
> > # Walreceiver sends this to the master when establishing the connection.
>
> The attached patch implements the above and simple synchronous replication
> feature, which doesn't include quorum commit capability. The replication
> mode (async, recv, fsync, replay) can be specified on a per-standby basis,
> in standbys.conf.
>
> The patch still uses a poll loop in the backend, walsender, startup process
> and walreceiver. If a latch feature Heikki proposed will have been committed,
> I'll replace that with a latch.

Now that the latch patch is in, when do you think you'll be able to use it
instead of the poll loop?

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2010-09-14 21:44:52 Re: Sync Replication with transaction-controlled durability
Previous Message Kevin Grittner 2010-09-14 20:42:37 Re: Serializable Snapshot Isolation