> > We could keep share buffer lock (or add some other kind of lock)
> > untill tuple projected - after projection we need not to read data
> > for fetched tuple from shared buffer and time between fetching
> > tuple and projection is very short, so keeping lock on buffer will
> > not impact concurrency significantly.
> 
> Or drop the pin on the buffer to show we no longer have a pointer
> to it. I'm not sure that the time to do projection is short though
> --- what if there are arbitrary user-defined functions in the quals
> or the projection targetlist?

Well, while we are on this subject I finally should say about issue
bothered me for long time: only "simple" functions should be allowed
to deal with data in shared buffers directly. "Simple" means: no SQL
queries there. Why? One reason: we hold shlock on buffer while doing
seqscan qual - what if qual' SQL queries will try to acquire exclock
on the same buffer? Another reason - concurrency. I think that such
"heavy" functions should be provided with copy of data.

Vadim

Mon, 21 May 2001 13:01:29 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Plans for solving the VACUUM problem 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
>> I'm not sure that the time to do projection is short though
>> --- what if there are arbitrary user-defined functions in the quals
>> or the projection targetlist?

> Well, while we are on this subject I finally should say about issue
> bothered me for long time: only "simple" functions should be allowed
> to deal with data in shared buffers directly. "Simple" means: no SQL
> queries there. Why? One reason: we hold shlock on buffer while doing
> seqscan qual - what if qual' SQL queries will try to acquire exclock
> on the same buffer?

I think we're there already: AFAICT, user-specified quals and
projections are done after dropping the buffer shlock.  (Yes, I know
there's a HeapKeyTest inside heapgettup, but user quals don't get
done there.)  We do still hold a pin, but that seems OK to me.

			regards, tom lane

Mon, 21 May 2001 16:46:34 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Plans for solving the VACUUM problem 