Sounds like a good plan. I found it quite easy to make changes link
this because mkid, and your tool glimpse, lets you pull up all functions
that contain a certain function or call to that function, pull them into
an editor, and away you go.
> Here's what I propose:
>
> Add another parameter to heap_open and heap_openr, which can be any of
> the lock types currently mentioned in storage/lmgr.h, or "NoLock".
> With "NoLock" you get the current behavior: no lock is acquired, and
> NULL is returned if the open fails; it's up to the caller to check that
> and do something appropriate. Otherwise, the routines will check for
> open failure and raise a standard elog(ERROR) if they do not succeed;
> furthermore, they will acquire the specified type of lock on the
> relation before returning. (And, thanks to the already-in-place call
> in LockRelation, any pending SI-inval messages will be read.)
>
> heap_close will also take an additional parameter, which is a lock type
> to release the specified lock, or NoLock to release no lock. (Note
> that it is often correct not to release the lock acquired at heap_open
> during heap_close; in this case, the lock is held till end of
> transaction. So, we don't want heap_close to automagically release
> whatever lock was acquired by the corresponding heap_open, even if it
> were easy to do so which it isn't...)
>
> If I don't hear any objections, I'll get on with implementing that.
>
> regards, tom lane
>
-- 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