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

Re: Synchronous replication, network protocol

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(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 12:40:46
Message-ID: 495A16CE.2020902@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Simon Riggs wrote:
> 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?

Using functions seems overly complicated. Since xids are system-wide, I 
don't see much value in specifying them at any finer level, or in 
allowing them for non-superusers. GUC seems like the natural choice.

I think the options you have in the patch now, and max_standby_delay to 
control it, is enough for this release.

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

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-12-30 13:54:43
Subject: Re: Synchronous replication, network protocol
Previous:From: Heikki LinnakangasDate: 2008-12-30 12:28:49
Subject: Re: window function docs

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