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

Sun, 07 Jan 2001 17:10:33 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Should heap_update/heap_delete hold buffer locks while toasting?
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 #



Mon, 8 Jan 2001 13:37:04 -0500 (EST)
Jan Wieck <janwieck@Yahoo.com>
Re: Should heap_update/heap_delete hold buffer locks while toasting?