Re: SIREAD lock versus ACCESS EXCLUSIVE lock

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, simon(at)2ndquadrant(dot)com, drkp(at)csail(dot)mit(dot)edu, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SIREAD lock versus ACCESS EXCLUSIVE lock
Date: 2011-06-07 18:10:05
Message-ID: 17163.1307470205@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> I think I've caught up with the rest of the class on why this isn't
> sane in DropAllPredicateLocksFromTableImpl, but I wonder about
> CheckTableForSerializableConflictIn. We *do* expect to be throwing
> errors in here, and we need some way to tell whether an index is
> associated with a particular heap relation. Is the catalog cache
> the right way to check that here, or is something else more
> appropriate?

Just to answer the question (independently of Heikki's concern about
whether this is needed at all): it depends on the information you have.
If all you have is the index OID, then yeah a catcache lookup in
pg_index is probably the best thing. If you have an open Relation for
the index, you could instead look into its cached copy of its pg_index
row. If you have an open Relation for the table, I'd think that looking
for a match in RelationGetIndexList() would be the cheapest, since more
than likely that information is already cached.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-06-07 18:10:06 Re: SIREAD lock versus ACCESS EXCLUSIVE lock
Previous Message Simon Riggs 2011-06-07 18:06:32 Re: reducing the overhead of frequent table locks - now, with WIP patch