On Mon, 2008-12-29 at 13:02 +0200, Heikki Linnakangas wrote:
> I haven't seen any one-size-fits-all solution to this issue, so we
> have to cater for many.
Very much agree. I've had the chance to speak to many people about the
way they would like this to work and there is definitely no consensus
from those users. So a variety of approaches is appropriate.
> Note that I proposed this exact scheme, where the
> slave sends its OldestXmin to the master, at the bottom of that same
> email.
Anyway, as long as it is optional, I see no problem in including it,
since we have other mechanisms to choose from and nobody is forced to
use this.
The design/implementation for this is fairly easy, I think.
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?
I now think we should provide (2) as well, in addition to this.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support