Thread: 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 #