On Fri, 2009-09-18 at 08:50 +0200, Albe Laurenz wrote: > Tom Lane wrote: > > > I don't see any reason why not breaking the user visible behavior of > > > tuples CTID between any two major releases, > > > > > Am I completely wet here? > > > > Completely. This is a user-visible behavior that we have encouraged > > people to rely on, and for which there is no easy substitute. > > I second that: it would hurt to lose this generic technique for > optimistic locking.
CTIDs don't help with optimistic locking, though it seems they can. If you don't hold open the transaction then someone else can update the row. That sounds good, but because of HOT it is possible that the same CTID with the same PK value occupies that exact CTID value when you return to check it. You think row has not been updated so you perform your update, but it has been updated, so you overwrite previous data - data loss. Actually worse, sporadic data loss because of race conditions. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers