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 15:11:16
Message-ID: 13667.1307459476@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:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> If you don't believe that a catcache lookup will ever fail, I will
>> contract to break the patch.

> As you probably know by now by reaching the end of the thread, this
> code is going away based on Heikki's arguments; but for my
> understanding, so that I don't make a bad assumption in this area
> again, what could cause the following function to throw an exception
> if the current process is holding an exclusive lock on the relation
> passed in to it? (I could be a heap or an index relation.) It
> seemed safe to me, and I can't spot the risk on a scan of the called
> functions. What am I missing?

Out-of-memory. Query cancel. The attempted catalog access failing
because it results in a detected deadlock. I could probably think of
several more if I spent ten minutes on it; and that's not even
considering genuine problem conditions such as a corrupted catalog
index, which robustness demands that we not fall over completely for.

You should never, ever assume that an operation as complicated as a
catalog lookup can't fail.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-06-07 15:15:38 Re: Range Types and extensions
Previous Message Merlin Moncure 2011-06-07 14:57:19 Re: Range Types and extensions