Should heap_update/heap_delete hold buffer locks while toasting?
The way that heap_update() and heap_delete() are currently coded, they
hold the buffer context lock on the buffer containing the old tuple
while they invoke heap_tuple_toast_attrs(). This strikes me as at least
inefficient and at worst a source of deadlock. Is it possible to avoid
holding the buffer lock while doing the TOAST manipulations?
regards, tom lane
Tom Lane wrote:
The way that heap_update() and heap_delete() are currently coded, they
hold the buffer context lock on the buffer containing the old tuple
while they invoke heap_tuple_toast_attrs(). This strikes me as at least
inefficient and at worst a source of deadlock. Is it possible to avoid
holding the buffer lock while doing the TOAST manipulations?
Since the TOAST table access is doing it's own locking on the
TOAST tables, I think it'd be possible to move it outside of
the buffer lock.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #