RE: [HACKERS] Re: [SQL] possible row locking bug in 7.0.3 & 7.1

[Mikheev, Vadim]

> > > I doubt if it's a bug of SELECT. Well what > > > 'concurrent UPDATE then SELECT FOR UPDATE + > > > SELECT' return ? > > > > I'm going to add additional check to heapgettup and > > heap_fetch: > > SELECT seems to be able to return a different result > from that of preceding SELECT FOR UPDATE even after > applying your change. Oh, you're right. Well, if we really want that SELECT returns the same result as SELECT FOR UPDATE *in functions* (out of functions results are already same) then we have to add some modifications to fix proposed: 1. If newer version of visible tuple T is marked for update by us *before* query began then do not return T. 2. If tuple T1 is *not visible* because of it was inserted by concurrent committed TX then check if it's marked for update by current TX *before* query began and return *this* tuple version if yes. This will be in accordance with standard which requires us return committed (whenever) rows in READ COMMITTED mode. In fact, in this mode our SELECTs provide higher isolation than required by standard returning rows committed *before* query began. Why? Because of SELECT doesn't lock rows and the same row may be visited by SELECT in join queries many times - so we have to be protected against concurrent updates. SELECT FOR UPDATE protects us BUT if query itself calls some functions which updates queried table then currently we may lose information that tuple was marked for update before query began - so updating tuple inserted by concurrent committed TX and marked for update by us we would have to save its t_cmax in t_cmin (and either add new flag to t_infomask or don't turn OFF HEAP_MARKED_FOR_UPDATE in this case). This is not what I would like to do in 7.1 > SELECT doesn't seem guilty but the result is far > from intuitive. I think that SELECT is guilty. At least returning two versions of the same row! (One that could be fixed easy). Vadim ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])