> Tom Lane wrote:
> >
> > Also, rather than running around and adding locks to every single
> > place that calls heap_open or heap_close, I wonder whether we shouldn't
> > have heap_open/heap_close themselves automatically grab or release
> > at least a minimal lock (AccessShareLock, I suppose).
>
> This could result in deadlocks...
>
> > Or maybe better: change heap_open/heap_openr/heap_close to take an
> > additional parameter specifying the kind of lock to grab. That'd still
> > mean having to visit all the call sites, but it would force people to
> > think about the issue in future rather than forgetting to lock a table
> > they're accessing.
>
> This way is better.
Just a reminder. heap_getnext() already locks the _buffer_, and
heap_fetch() requires you pass a variable to hold the buffer number, so
you can release the buffer lock when you are done.
This was not the case in < 6.4 releases, and there is no reason not to
add additional parameters to function calls like I did for heap_fetch() if
it makes sense.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026