Skip site navigation (1) Skip section navigation (2)

Re: Synchronous replication, network protocol

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Pavan Deolasee <pavan(dot)deolasee(at)enterprisedb(dot)com>
Subject: Re: Synchronous replication, network protocol
Date: 2008-12-30 10:42:45
Message-ID: 1230633765.4793.1239.camel@ebony.2ndQuadrant (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, 2008-12-29 at 13:02 +0200, Heikki Linnakangas wrote:

> I haven't seen any one-size-fits-all solution to this issue, so we
> have to cater for many. 

Very much agree. I've had the chance to speak to many people about the
way they would like this to work and there is definitely no consensus
from those users. So a variety of approaches is appropriate.

> Note that I proposed this exact scheme, where the 
> slave sends its OldestXmin to the master, at the bottom of that same
> email.

Anyway, as long as it is optional, I see no problem in including it,
since we have other mechanisms to choose from and nobody is forced to
use this.

The design/implementation for this is fairly easy, I think. 

The difficulty is arriving at an easy-to-use control mechanism that is
also secure.

The options for handling a conflict are these:
1. Ignore the conflict (and allow silent wrong answers)
2. Allow the conflicting query to progress until it sees changed data
3. Cancel the query
4. Prevent applying WAL
5. Feed OldestXmin back to primary to prevent conflicting WAL

The current mechanism is (4) for up to max_standby_delay, then (3).

(4) and (5) are both system wide effects: (4) system wide effect on the
standby and (5) is a system wide effect on primary. In both of those
cases that option should be super-user only controlled. I would be
unhappy to think that a normal standby user could create
difficult-to-diagnose problems on primary.

So I see a problem in making (5) optional and super-user controlled. 

One way around this is to have the option turn on|off via a function,
which can then be granted to other users.

That for me is beginning to sound fairly ugly: difficult to understand
and difficult to use. But I see some people might want that in certain
circumstances. So I guess we should build it. Any good ideas for the
control mechanism?

I now think we should provide (2) as well, in addition to this.

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


In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2008-12-30 12:28:49
Subject: Re: window function docs
Previous:From: Peter EisentrautDate: 2008-12-30 09:05:35
Subject: Re: about truncate

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group