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.
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2008-12-30 13:54:43|
|Subject: Re: Synchronous replication, network protocol|
|Previous:||From: Heikki Linnakangas||Date: 2008-12-30 12:28:49|
|Subject: Re: window function docs|