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