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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
