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
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 |