aboutsummaryrefslogtreecommitdiff
path: root/contrib/btree_gist/btree_inet.c
diff options
context:
space:
mode:
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>2011-03-01 19:05:16 +0200
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>2011-03-01 19:05:16 +0200
commit47ad79122bc099c1f0ea8a7ae413fcd8d45e26a6 (patch)
treeb8a4ac5fa3cff5235a5693ca31825ecbcfdd97db /contrib/btree_gist/btree_inet.c
parent16143d64513e4dc3c72bad7ae98d3df0b5a23013 (diff)
downloadpostgresql-47ad79122bc099c1f0ea8a7ae413fcd8d45e26a6.tar.gz
postgresql-47ad79122bc099c1f0ea8a7ae413fcd8d45e26a6.zip
Fix bugs in Serializable Snapshot Isolation.
Change the way UPDATEs are handled. Instead of maintaining a chain of tuple-level locks in shared memory, copy any existing locks on the old tuple to the new tuple at UPDATE. Any existing page-level lock needs to be duplicated too, as a lock on the new tuple. That was neglected previously. Store xmin on tuple-level predicate locks, to distinguish a lock on an old already-recycled tuple from a new tuple at the same physical location. Failure to distinguish them caused loops in the tuple-lock chains, as reported by YAMAMOTO Takashi. Although we don't use the chain representation of UPDATEs anymore, it seems like a good idea to store the xmin to avoid some false positives if no other reason. CheckSingleTargetForConflictsIn now correctly handles the case where a lock that's being held is not reflected in the local lock table. That happens if another backend acquires a lock on our behalf due to an UPDATE or a page split. PredicateLockPageCombine now retains locks for the page that is being removed, rather than removing them. This prevents a potentially dangerous false-positive inconsistency where the local lock table believes that a lock is held, but it is actually not. Dan Ports and Kevin Grittner
Diffstat (limited to 'contrib/btree_gist/btree_inet.c')
0 files changed, 0 insertions, 0 deletions