Re: SSI-related code drift between index_getnext() and heap_hot_search_buffer()

On Thu, May 12, 2011 at 7:02 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Anyway, I could clean up all but that last issue in the old code.
> I'm not sure whether that makes sense if you're refactoring it
> anyway.  Would you like me to look at the refactored code to suggest
> fixes?  Would you rather do it yourself based on my answers here?
> Do we need to sort out that last issue before proceeding on the
> others?

First, in contrast to your promise to respond with answers in an hour
or two, that was three hours and one minute. Stop slacking off![1]

Second, I haven't a clue how to fix this. What I was doing was of
course targeted toward 9.2, but I have half a thought that making
index_getnext() call heap_hot_search_buffer() might be a sensible
thing to do in 9.1, because code duplication = more bugs. On the
third hand, at the moment the code that Heikki wrote to do that is
tangled up in a bunch of other things that we almost certainly don't
want to do in 9.1, and it's not obvious that it can be cleanly
untangled, so maybe that's not the right idea after all.

I think a good starting point might be to design a test case that
fails with the current code, and come up with a plan for what to do
about it. I have a very ugly feeling about this problem. I agree
with your feeling that chasing down the update pointers isn't
sensible, but a whole-relation lock seems like it could lead to a lot
more rollbacks.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

[1] For the benefit of anyone on the audience who lacks a sense of
humor, this is a joke.