Re: SSI bug?

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Dan Ports" <drkp(at)csail(dot)mit(dot)edu>
Cc: <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "YAMAMOTO Takashi" <yamt(at)mwd(dot)biglobe(dot)ne(dot)jp>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI bug?
Date: 2011-02-22 16:51:05
Message-ID: 4D639519020000250003AE0D@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dan Ports <drkp(at)csail(dot)mit(dot)edu> wrote:

> It looks like CheckTargetForConflictsIn is making the assumption
> that the backend-local lock table is accurate, which was probably
> even true at the time it was written.

I remember we decided that it could only be false in certain ways
which allowed us to use it as a "lossy" first-cut test in a couple
places. I doubt that we can count on any of that any longer, and
should drop those heuristics.

> the new changes for tuple versions make it more likely that this
> will actually come up.

Yeah, as far as a I can recall the only divergence was in *page*
level entries for *indexes* until this latest patch. We now have
*tuple* level entries for *heap* relations, too.

> The solution is only slightly more complicated than just removing
> the assertion.

That's certainly true for that one spot, but we need an overall
review of where we might be trying to use LocalPredicateLockHash for
"first cut" tests as an optimization.

> Unless Kevin beats me to it, I'll put together a patch later
> tonight or tomorrow. (I'm at the airport right now.)

It would be great if you could get this one. Thanks.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-02-22 16:54:47 Re: pg_basebackup and wal streaming
Previous Message Alvaro Herrera 2011-02-22 16:40:25 Re: pg_resetxlog display bogosity