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 Branch ------ REL9_3_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/4c71f48f4c6c923d1b3f6e6c788e8a0995f4241a Modified Files -------------- src/backend/access/heap/heapam.c | 202 ++++++++++++++++++++++++++++++++------ 1 file changed, 171 insertions(+), 31 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
