Re: Sync Rep: First Thoughts on Code

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: aidan(at)highrise(dot)ca, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Sync Rep: First Thoughts on Code
Date: 2008-12-12 11:35:07
Message-ID: 1229081707.13078.259.camel@hp_dx2400_1
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Fri, 2008-12-12 at 12:53 +0900, Fujii Masao wrote:
> >
> > Quite possibly a terminology problem.. I my case I said "sync rep"
> > meaning the mode such that the transaction doesn't commit successfully
> > for my PG client until the xlog record has been "streamed" to the
> > client... and I understand that at his presentation at PGcon, Fujii-san
> > there could be possible variants on when the "streamed" is considered
> > done based on network, slave ram, disk, application, etc.
>
> I'd like to define the meaning of "synch rep" again. "synch rep" means:
>
> (1) Transaction commit waits for WAL records to be replicated to the standby
> before the command returns a "success" indication to the client.

> (2) The standby has (can read) all WAL files indispensable for recovery.

I would change "can read" in (2) to "has access to". "Can read" implies
we have read all files and checked CRCs of individual records.

The crux of this is what we mean by "synchronous_replication = on".
There are two possible meanings:

1. Commit will wait only if streaming is available and has waited for
all necessary startup conditions.
This provides "Highest Availability"

2. Commit will wait *until* full sync rep is available. So we don't
allow it until standby fails and also don't allow it if standby goes
down.
This provides "Highest Transaction Durability", though is fairly
fragile. Other systems recommend use of multiple standby nodes if this
option is selected.

Perhaps we should add this as a third option to synchronous_replication,
so we have either off, on, only

So far I realise I've been talking exclusively about (1). In that mode
synchronous_replication = on would wait for streaming to complete even
if last WAL file not fully transferred.

For (2) we need a full interlock. Given that we don't currently support
multiple streamed standby servers, it seems not much point in
implementing the interlock (2) would require. Should we leave that part
for 8.5, or do it now?

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-12-12 11:43:48 [Patch] Space reservation (pgupgrade)
Previous Message Fujii Masao 2008-12-12 09:56:25 Re: Sync Rep: First Thoughts on Code