| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
|---|---|
| To: | <drkp(at)csail(dot)mit(dot)edu>,<heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Repeated PredicateLockRelation calls during seqscan |
| Date: | 2011-06-25 19:29:38 |
| Message-ID: | 4E05F0D2020000250003EC1D@gw.wicourts.gov |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> BTW, isn't bitgetpage() in nodeBitmapHeapscan.c missing
> PredicateLockTuple() and CheckForSerializableConflictOut() calls in
> the codepath for a lossy bitmap? In the non-lossy case,
> heap_hot_search_buffer() takes care of it, but not in the lossy
> case.
I think the attached addresses that.
In looking this over I noticed something else that doesn't seem quite
right. In heapam.c there are two places where the execution of
PredicateLockTuple() is conditioned not just on MVCC visibility, but
also on HeapKeyTest(). I think those calls should be moved to not be
conditioned on that. Otherwise we have a predicate condition being
tested without "locking the gaps", don't we?
-Kevin
| Attachment | Content-Type | Size |
|---|---|---|
| ssi-lossy-bitmap.patch | application/octet-stream | 1.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2011-06-25 20:36:33 | Re: possible connection leak in dblink? |
| Previous Message | Jeff Davis | 2011-06-25 10:24:45 | Re: heap_hot_search_buffer refactoring |