Simon Riggs wrote: > 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.
Yeah, you have to check xmin as well. -- 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
