From: Tom Lane on 31 Jul 2010 09:57 I fixed the problem I was on about earlier with ginget.c doing the wrong thing for keystreams like this: ... ... 42/6 42/65535 42/7 ... ... (To recap, after reporting the potential lossy match for 42/6, the previous code would advance both keystreams and thus fail to see the potential lossy match for 42/7.) But in the shower this morning I realized there was another case I had not considered: ... ... 42/6 42/7 50/1 42/65535 ... ... After deciding there is no possible match at 42/6, both the original code and my patch will choose to advance the first keystream. This means they will never compare 42/6 to the lossy pointer and recognize there's a potential lossy match. So far as I can see, it's impossible to handle this situation when examining only one TID per stream with no lookahead. Choosing to advance the second stream would obviously fail in many other cases, so there is no correct action. The only reasonable way out is to forbid the case --- that is, decree that a keystream may *not* contain both lossy and nonlossy pointers to the same page. Now it looks to me like there's no actual bug so far as keyGetItem is concerned, because in fact that's how entryGetItem will behave: it can only return a lossy pointer when a partial match bitmap has gone lossy, and then the bitmap won't return any real pointers to that page. However it *is* possible for the revised version of keyGetItem to return such a keystream, thus breaking scanGetItem. The problematic case is where the consistentFn has OR logic and we have a situation like ... ... 42/6 42/65535 50/1 ... ... We'll correctly report 42/6 as a lossy result, but then the next call will advance only the first keystream, and decide that it needs to test nothing-and-42/65535 as a possible match. Given an OR query, that'll succeed, and we'll return 42/65535 next, thus breaking the rule that needs to hold for scanGetItem. So this looks like a bit of a mess to resolve. I think what we have to do is first see if the consistentFn will succeed when only the lossy stream is TRUE, and if so report the whole-page pointer as a lossy match (and advance over it as well as all the non-lossy pointers for the same page on the next call). Otherwise continue as now. In any case the code comments are all wet because they state that a keystream with both lossy and nonlossy pointers on the same page is OK. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Pages: 1 Prev: review: xml_is_well_formed Next: ANALYZE versus expression indexes with nondefault opckeytype |