"Kevin Grittner" wrote: > "Kevin Grittner" wrote: >> 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. > > Don't commit that patch, it's not holding up in testing here. > > I'll look at it some more. Version 2 is attached. It initializes some data which was uninitialized in a HeapTableData structure which already existed in the code. I've been burned by this before -- making a seemingly innocuous change to code which then fails because the comments at lines 512 to 514 in htup.h are not actually true: http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/include/access/htup.h;h=ba5d9b28ef19f3054191cf0f8b358ac5831a9e26;hb=8af3596d6bb6cfffb57161a62aa2f7f56d5ea3eb#l504 I asked about this the first time it bit me in this thread: http://archives.postgresql.org/pgsql-hackers/2010-03/msg00493.php which concluded here: http://archives.postgresql.org/pgsql-hackers/2010-03/msg00506.php Having been bitten by it a *second* time now, I'm inclined to go through and make the code match the comments wherever these structures are used. It's a bit late in the cycle to do that for 9.1, but I'll get something on the table for 9.2 if nobody wants to argue against that course. -Kevin
ssi-lossy-bitmap-2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
