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