Re: Synchronous replication, network protocol

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