Re: Sync Rep: First Thoughts on Code - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Sync Rep: First Thoughts on Code
Date
Msg-id 1229081707.13078.259.camel@hp_dx2400_1
Whole thread Raw
In response to Re: Sync Rep: First Thoughts on Code  ("Fujii Masao" <masao.fujii@gmail.com>)
Responses Re: Sync Rep: First Thoughts on Code
List 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.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: "Ian Caulfield"
Date:
Subject: Re: WIP: default values for function parameters
Next
From: Zeugswetter Andreas OSB sIT
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)