]> git.ipfire.org Git - thirdparty/postgresql.git/commit
projects / thirdparty / postgresql.git / commit
? search:
summary | shortlog | log | commit | commitdiff | tree
(parent: 2a4b6ee) | patch
Use a more granular approach to follow update chains
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Wed, 27 Nov 2013 20:50:33 +0000 (17:50 -0300)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Thu, 28 Nov 2013 14:54:25 +0000 (11:54 -0300)
commit4c71f48f4c6c923d1b3f6e6c788e8a0995f4241a
tree94c9906206249f18b528f887b12e9ca336daeb6ctree
parent2a4b6eed0916a8fdc57b4778ecb1463fe752d369commit | diff
Use a more granular approach to follow update chains

Instead of simply checking the KEYS_UPDATED bit, we need to check
whether each lock held on the future version of the tuple conflicts with
the lock we're trying to acquire.

Per bug report #8434 by Tomonari Katsumata
src/backend/access/heap/heapam.c diff | blob | blame | history
Mirror of https://git.postgresql.org/git/postgresql.git