On Wed, Jun 22, 2011 at 12:07:04PM +0300, Heikki Linnakangas wrote: > Hmm, I wonder if we should move this logic to heapam.c. The optimization > to acquire a relation lock straight away should apply to all heap scans, > not only those coming from ExecSeqScan. The distinction is academic at > the moment, because that's the only caller that uses a regular MVCC > snapshot, but it seems like a modularity violation for nodeSeqscan.c to > reach into the HeapScanDesc to set the flag and grab the whole-relation > lock, while heapam.c contains the PredicateLockTuple and > CheckForSerializableConflictOut() calls.
On modularity grounds, I think that's a good idea. The other PredicateLock* calls live in the access methods: heapam, nbtree, and indexam for the generic index support. heap_beginscan_internal seems like a reasonable place, as long as we're OK with taking the lock even if the scan is initialized but never called. Note that this hadn't been a reasonable option until last week when we added the check for non-MVCC snapshots, since there are lots of things that use heap scans but SeqScan is the only (currently-existing) one we want to lock. I am rather uneasy about making changes here unless we can be absolutely certain they're right... Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
