RE: Plans for solving the VACUUM problem - Mailing list pgsql-hackers

From Mikheev, Vadim
Subject RE: Plans for solving the VACUUM problem
Date
Msg-id 3705826352029646A3E91C53F7189E3201663A@sectorbase2.sectorbase.com
Whole thread Raw
In response to Plans for solving the VACUUM problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Plans for solving the VACUUM problem  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > 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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Detecting readline in configure
Next
From: Barry Lind
Date:
Subject: Re: AW: Plans for solving the VACUUM problem