pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedAccessExclusiveLock on CREATE TABLE REFERENCES deadlocks
5+ messages / 3 participants
[nested] [flat]
* AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks
@ 2009-09-22 16:41 Bryce Nesbitt <bryce2@obviously.com>
0 siblings, 0 replies; 5+ messages in thread
From: Bryce Nesbitt @ 2009-09-22 16:41 UTC (permalink / raw)
To: pgsql-sql
Dear Postgres Gurus;
I've just diagnosed a PostgreSQL 8.3.4 server which, about once a month,
would deadlock shortly after 11pm. It had been doing this for years,
and the prior response was simply to reboot everything. The culprit
boils down to:
# create table cache_table_20090921 (
site_key int NOT NULL REFERENCES contexts(context_key),
blah_blah TEXT NULL,
PRIMARY KEY (site_key)
);
Without the REFERENCES this is a very fast operation and always works.
Adding "DEFERRABLE INITIALLY DEFERRED" or "ON DELETE CASCADE" (as the
original did) makes no difference. With any REFERENCES, the create
table may blocks a long time (up to 45 minutes and counting), all while
attempting to get an AccessExclusiveLock. The server quickly backs up,
simple select statements block, the server maxes out the number of
incoming apache connections, things start swapping, and generally it all
gets into a huge tangle:
# SELECT l.locktype,c.relname,l.pid,l.mode,granted from pg_locks
l,pg_class c where l.relation=c.oid order by relname,granted;
locktype | relname | pid |
mode | granted
relation | article_key_idx | 18891 |
AccessShareLock | t
relation | articles | 18891 |
AccessShareLock | t
relation | articles_editorid_idx | 18891 |
AccessShareLock | t
relation | articles_pkey | 18891 |
AccessShareLock | t
relation | articles_response_to_key_idx | 18891 |
AccessShareLock | t
relation | articles_state_idx | 18891 |
AccessShareLock | t
relation | article_words | 18891 |
AccessShareLock | t
relation | article_words_cw | 18891 |
AccessShareLock | t
relation | article_words_wc | 18891 |
AccessShareLock | t
relation | collection_context_key_idx | 18891 |
AccessShareLock | t
relation | collection_owner_key_idx | 18891 |
AccessShareLock | t
relation | collections | 18891 |
AccessShareLock | t
relation | context_publication_key_idx | 18891 |
AccessShareLock | t
relation | contexts | 18891 |
AccessShareLock | t <--------- HERE
relation | contexts | 3879 |
AccessExclusiveLock | f
relation | contexts | 5477 |
AccessShareLock | f
relation | contexts | 5484 |
AccessShareLock | f
relation | contexts | 5485 |
AccessShareLock | f
relation | contexts | 5486 |
AccessShareLock | f
relation | contexts | 5487 |
AccessShareLock | f
relation | contexts | 5489 |
AccessShareLock | f
relation | contexts | 5493 |
AccessShareLock | f
relation | contexts | 5494 |
AccessShareLock | f
relation | contexts | 5496 |
AccessShareLock | f
relation | contexts | 5497 |
AccessShareLock | f
relation | contexts | 5498 |
AccessShareLock | f
relation | contexts | 5499 |
AccessShareLock | f
relation | contexts | 5500 |
AccessShareLock | f
relation | contexts | 5502 |
AccessShareLock | f
relation | contexts | 5503 |
AccessShareLock | f
relation | contexts | 5504 |
AccessShareLock | f
relation | contexts | 5505 |
AccessShareLock | f
relation | contexts | 5506 |
AccessShareLock | f
relation | contexts | 5507 |
AccessShareLock | f
relation | contexts | 5508 |
AccessShareLock | f
relation | contexts | 5509 |
AccessShareLock | f
relation | contexts | 5510 |
AccessShareLock | f
relation | contexts | 5511 |
AccessShareLock | f
relation | contexts | 5512 |
AccessShareLock | f
relation | contexts | 5515 |
AccessShareLock | f
relation | contexts | 5516 |
AccessShareLock | f
relation | contexts | 5517 |
AccessShareLock | f
relation | contexts | 5518 |
AccessShareLock | f
relation | contexts | 5519 |
AccessShareLock | f
relation | contexts | 5520 |
AccessShareLock | f
relation | contexts | 5521 |
AccessShareLock | f
relation | contexts | 5523 |
AccessShareLock | f
relation | contexts | 5524 |
AccessShareLock | f
relation | contexts_id_key | 18891 |
AccessShareLock | t
relation | contexts_pkey | 18891 |
AccessShareLock | t
relation | contexts_publication_date_idx | 18891 |
AccessShareLock | t
relation | contexts_site_key_ct_id_journal_key | 18891 |
AccessShareLock | t
relation | contexts_site_key_ct_type_idx | 18891 |
AccessShareLock | t
relation | group_key_idx | 18891 |
AccessShareLock | t
relation | parent_key_idx | 18891 |
AccessShareLock | t
relation | pg_class | 3911 |
AccessShareLock | t
relation | pg_class_oid_index | 3911 |
AccessShareLock | t
relation | pg_class_relname_nsp_index | 3911 |
AccessShareLock | t
relation | pg_locks | 3911 |
AccessShareLock | t
relation | site_key_idx | 18891 |
AccessShareLock | t
relation | virtual_ancestor_key_idx | 18891 |
AccessShareLock | t
relation | virtual_ancestors | 18891 |
AccessShareLock | t
relation | virtual_ancestors_pkey | 18891 |
AccessShareLock | t
relation | virtual_context_key_idx | 18891 |
AccessShareLock | t
relation | words | 18891 |
AccessShareLock | t
relation | words_pkey | 18891 |
AccessShareLock | t
relation | words_word | 18891 |
AccessShareLock | t
# select pg_size_pretty(pg_total_relation_size('contexts_pkey'));
35MB
# select pg_size_pretty(pg_total_relation_size('contexts'));
787MB
# select pg_cancel_backend(3879)
t
And all is well again.
-----------------------------------------------------------------------------------------------------------------
So my questions are various
1) Why the AccessExclusiveLock on create table?
2) Why is the foreign key check a heavy operation, since a new table
will have zero foreign keys, it can't possibly violate the constraint yet.
3) Other than eliminating dynamic table creation, how can this operation
be altered?
4) Is there more data I should collect about the lock (e.g. do I have a
good lock summary select statement)?
Note that process 18891 in the example is doing a select:
--------------
SELECT contexts.context_key FROM contexts
: JOIN articles ON
(articles.context_key=contexts.context_key)
: WHERE contexts.context_key IN
(SELECT context_key FROM article_words JOIN words using (word_key) WHERE
word = 'four')
: AND contexts.context_key IN
(SELECT context_key FROM article_words JOIN words using (word_key) WHERE
word = 'step')
: AND contexts.context_key IN
(SELECT context_key FROM article_words JOIN words using (word_key) WHERE
word = 'control')
: AND contexts.context_key IN
(SELECT context_key FROM article_words JOIN words using (word_key) WHERE
word = 'process')
: AND contexts.context_key IN
(SELECT context_key FROM article_words JOIN words using (word_key) WHERE
word = 'business')
: AND contexts.context_key IN
: (SELECT DISTINCT
a1.context_key FROM virtual_ancestors a1, collections, virtual_ancestors a2
: WHERE a1.ancestor_key
= collections.context_key AND collections.owner_key = a2.context_key AND
a2.ancestor_key = '8
2034')
: AND articles.indexed
: ORDER BY
contexts.publication_date DESC;
^ permalink raw reply [nested|flat] 5+ messages in thread
* AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better)
@ 2009-09-22 16:55 Bryce Nesbitt <bryce2@obviously.com>
2009-09-22 17:35 ` Re: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better) Tom Lane <tgl@sss.pgh.pa.us>
2009-10-07 05:25 ` Re: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better) Erik Jones <ejones@engineyard.com>
0 siblings, 2 replies; 5+ messages in thread
From: Bryce Nesbitt @ 2009-09-22 16:55 UTC (permalink / raw)
To: pgsql-sql
Dear Postgres Gurus;
I've just diagnosed a PostgreSQL 8.3.4 server which, about once a month, would deadlock shortly after 11pm. It had been doing this for years,
and the prior response was simply to reboot everything. The culprit boils down to:
# create table cache_table_20090921 (
site_key int NOT NULL REFERENCES contexts(context_key),
blah_blah TEXT NULL,
PRIMARY KEY (site_key)
);
Without the REFERENCES this is a very fast operation and always works.
Adding "DEFERRABLE INITIALLY DEFERRED" or "ON DELETE CASCADE" (as the original did) makes no difference. With any REFERENCES, the create table may block a long time (up to 45 minutes and counting), all while attempting to get an AccessExclusiveLock. The server quickly backs up,
simple select statements block, the server maxes out the number of incoming apache connections, things start swapping, and generally it all gets into a huge tangle:
# SELECT l.locktype,c.relname,l.pid,l.mode,granted from pg_locks l,pg_class c where l.relation=c.oid order by relname,granted;
locktype | relname | pid | mode | granted
relation | article_key_idx | 18891 | AccessShareLock | t
relation | articles | 18891 | AccessShareLock | t
relation | articles_editorid_idx | 18891 | AccessShareLock | t
relation | articles_pkey | 18891 | AccessShareLock | t
relation | articles_response_to_key_idx | 18891 | AccessShareLock | t
relation | articles_state_idx | 18891 | AccessShareLock | t
relation | article_words | 18891 | AccessShareLock | t
relation | article_words_cw | 18891 | AccessShareLock | t
relation | article_words_wc | 18891 | AccessShareLock | t
relation | collection_context_key_idx | 18891 | AccessShareLock | t
relation | collection_owner_key_idx | 18891 | AccessShareLock | t
relation | collections | 18891 | AccessShareLock | t
relation | context_publication_key_idx | 18891 | AccessShareLock | t
relation | contexts | 18891 | AccessShareLock | t
relation | contexts | 3879 | AccessExclusiveLock | f
relation | contexts | 5477 | AccessShareLock | f
relation | contexts | 5484 | AccessShareLock | f
relation | contexts | 5485 | AccessShareLock | f
relation | contexts | 5486 | AccessShareLock | f
relation | contexts | 5487 | AccessShareLock | f
relation | contexts | 5489 | AccessShareLock | f
relation | contexts | 5493 | AccessShareLock | f
relation | contexts | 5494 | AccessShareLock | f
relation | contexts | 5496 | AccessShareLock | f
relation | contexts | 5497 | AccessShareLock | f
relation | contexts | 5498 | AccessShareLock | f
relation | contexts | 5499 | AccessShareLock | f
relation | contexts | 5500 | AccessShareLock | f
relation | contexts | 5502 | AccessShareLock | f
relation | contexts | 5503 | AccessShareLock | f
relation | contexts | 5504 | AccessShareLock | f
relation | contexts | 5505 | AccessShareLock | f
relation | contexts | 5506 | AccessShareLock | f
relation | contexts | 5507 | AccessShareLock | f
relation | contexts | 5508 | AccessShareLock | f
relation | contexts | 5509 | AccessShareLock | f
relation | contexts | 5510 | AccessShareLock | f
relation | contexts | 5511 | AccessShareLock | f
relation | contexts | 5512 | AccessShareLock | f
relation | contexts | 5515 | AccessShareLock | f
relation | contexts | 5516 | AccessShareLock | f
relation | contexts | 5517 | AccessShareLock | f
relation | contexts | 5518 | AccessShareLock | f
relation | contexts | 5519 | AccessShareLock | f
relation | contexts | 5520 | AccessShareLock | f
relation | contexts | 5521 | AccessShareLock | f
relation | contexts | 5523 | AccessShareLock | f
relation | contexts | 5524 | AccessShareLock | f
relation | contexts_id_key | 18891 | AccessShareLock | t
relation | contexts_pkey | 18891 | AccessShareLock | t
relation | contexts_publication_date_idx | 18891 | AccessShareLock | t
relation | contexts_site_key_ct_id_journal_key | 18891 | AccessShareLock | t
relation | contexts_site_key_ct_type_idx | 18891 | AccessShareLock | t
relation | group_key_idx | 18891 | AccessShareLock | t
relation | parent_key_idx | 18891 | AccessShareLock | t
relation | pg_class | 3911 | AccessShareLock | t
relation | pg_class_oid_index | 3911 | AccessShareLock | t
relation | pg_class_relname_nsp_index | 3911 | AccessShareLock | t
relation | pg_locks | 3911 | AccessShareLock | t
relation | site_key_idx | 18891 | AccessShareLock | t
relation | virtual_ancestor_key_idx | 18891 | AccessShareLock | t
relation | virtual_ancestors | 18891 | AccessShareLock | t
relation | virtual_ancestors_pkey | 18891 | AccessShareLock | t
relation | virtual_context_key_idx | 18891 | AccessShareLock | t
relation | words | 18891 | AccessShareLock | t
relation | words_pkey | 18891 | AccessShareLock | t
relation | words_word | 18891 | AccessShareLock | t
# select pg_size_pretty(pg_total_relation_size('contexts_pkey'));
35MB
# select pg_size_pretty(pg_total_relation_size('contexts'));
787MB
# select pg_cancel_backend(3879)
t
And all is well again.
-----------------------------------------------------------------------------------------------------------------
So my questions are various
1) Why the AccessExclusiveLock on create table?
2) Why is the foreign key check a heavy operation, since a new table
will have zero foreign keys, it can't possibly violate the constraint yet.
3) Other than eliminating dynamic table creation, how can this operation
be altered?
4) Is there more data I should collect about the lock (e.g. do I have a
good lock summary select statement)?
Note that process 18891 in the example is doing a select:
--------------
SELECT contexts.context_key FROM contexts
JOIN articles ON
(articles.context_key=contexts.context_key)
WHERE contexts.context_key IN
(SELECT context_key FROM article_words JOIN words using (word_key) WHERE word = 'four')
AND contexts.context_key IN
(SELECT context_key FROM article_words JOIN words using (word_key) WHERE word = 'step')
AND contexts.context_key IN
(SELECT context_key FROM article_words JOIN words using (word_key) WHERE word = 'control')
AND contexts.context_key IN
(SELECT context_key FROM article_words JOIN words using (word_key) WHERE word = 'process')
AND contexts.context_key IN
(SELECT context_key FROM article_words JOIN words using (word_key) WHERE word = 'business')
AND contexts.context_key IN (SELECT DISTINCT
a1.context_key FROM virtual_ancestors a1, collections, virtual_ancestors a2
WHERE a1.ancestor_key = collections.context_key AND collections.owner_key = a2.context_key AND a2.ancestor_key = '82034')
AND articles.indexed
ORDER BY contexts.publication_date DESC;
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better)
2009-09-22 16:55 AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better) Bryce Nesbitt <bryce2@obviously.com>
@ 2009-09-22 17:35 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-09-23 00:10 ` Re: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better) Bryce Nesbitt <bryce2@obviously.com>
1 sibling, 1 reply; 5+ messages in thread
From: Tom Lane @ 2009-09-22 17:35 UTC (permalink / raw)
To: Bryce Nesbitt <bryce2@obviously.com>; +Cc: pgsql-sql
Bryce Nesbitt <bryce2@obviously.com> writes:
> 1) Why the AccessExclusiveLock on create table?
It has to install a trigger on the referenced table. There has been
some discussion that maybe CREATE TRIGGER could take just ExclusiveLock
and not AccessExclusiveLock, but it hasn't been done yet; and I'm not
sure how much that would help you anyway. It would only help if the
referenced table (contexts) is essentially read-only to the rest of
your workload, else it'll block anyhow.
> 2) Why is the foreign key check a heavy operation, since a new table
> will have zero foreign keys, it can't possibly violate the constraint yet.
It's not a heavy operation in that case. The problem doubtless is that
it's backed up behind some other transaction that is sitting on a lock
on the contexts table. And then everything else backs up behind it.
> 3) Other than eliminating dynamic table creation, how can this operation
> be altered?
Get rid of long-running transactions that hold locks on the contexts
table.
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better)
2009-09-22 16:55 AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better) Bryce Nesbitt <bryce2@obviously.com>
2009-09-22 17:35 ` Re: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better) Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-09-23 00:10 ` Bryce Nesbitt <bryce2@obviously.com>
0 siblings, 0 replies; 5+ messages in thread
From: Bryce Nesbitt @ 2009-09-23 00:10 UTC (permalink / raw)
To: pgsql-sql
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Tom Lane wrote:
<blockquote cite="mid:13526.1253640939@sss.pgh.pa.us" type="cite">
<pre wrap="">Bryce Nesbitt <a class="moz-txt-link-rfc2396E" href="mailto:bryce2@obviously.com"><bryce2@obviously.com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">1) Why the AccessExclusiveLock on create table?
</pre>
</blockquote>
<pre wrap=""><!---->
It has to install a trigger on the referenced table. There has been
some discussion that maybe CREATE TRIGGER could take just ExclusiveLock
and not AccessExclusiveLock, but it hasn't been done yet; and I'm not
sure how much that would help you anyway. It would only help if the
referenced table (contexts) is essentially read-only to the rest of
your workload, else it'll block anyhow.</pre>
</blockquote>
Thanks for the great info.<br>
<br>
In our case all the long running access is read-only. We have a poorly
designed table that several postgres consultants have burned out on
trying to fix.<br>
<br>
Most notably there are also zillions of short read-only references that
presently block while the create table attempts to gain the
AccessExclusiveLock. <br>
<br>
-Bryce<br>
</body>
</html>
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better)
2009-09-22 16:55 AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better) Bryce Nesbitt <bryce2@obviously.com>
@ 2009-10-07 05:25 ` Erik Jones <ejones@engineyard.com>
1 sibling, 0 replies; 5+ messages in thread
From: Erik Jones @ 2009-10-07 05:25 UTC (permalink / raw)
To: Bryce Nesbitt <bryce2@obviously.com>; +Cc: pgsql-sql
On Sep 22, 2009, at 9:55 AM, Bryce Nesbitt wrote:
> # SELECT l.locktype,c.relname,l.pid,l.mode,granted from pg_locks
> l,pg_class c where l.relation=c.oid order by relname,granted;
> locktype | relname | pid |
> mode | granted
> relation | article_key_idx | 18891 |
> AccessShareLock | t
> relation | articles | 18891 |
> AccessShareLock | t
> relation | articles_editorid_idx | 18891 |
> AccessShareLock | t
> relation | articles_pkey | 18891 |
> AccessShareLock | t
> relation | articles_response_to_key_idx | 18891 |
> AccessShareLock | t
> relation | articles_state_idx | 18891 |
> AccessShareLock | t
> relation | article_words | 18891 |
> AccessShareLock | t
> relation | article_words_cw | 18891 |
> AccessShareLock | t
> relation | article_words_wc | 18891 |
> AccessShareLock | t
> relation | collection_context_key_idx | 18891 |
> AccessShareLock | t
> relation | collection_owner_key_idx | 18891 |
> AccessShareLock | t
> relation | collections | 18891 |
> AccessShareLock | t
> relation | context_publication_key_idx | 18891 |
> AccessShareLock | t
> relation | contexts | 18891 |
> AccessShareLock | t
> relation | contexts | 3879 |
> AccessExclusiveLock | f
> relation | contexts | 5477 |
> AccessShareLock | f
> relation | contexts | 5484 |
> AccessShareLock | f
> relation | contexts | 5485 |
> AccessShareLock | f
> relation | contexts | 5486 |
> AccessShareLock | f
> relation | contexts | 5487 |
> AccessShareLock | f
> relation | contexts | 5489 |
> AccessShareLock | f
> relation | contexts | 5493 |
> AccessShareLock | f
> relation | contexts | 5494 |
> AccessShareLock | f
> relation | contexts | 5496 |
> AccessShareLock | f
> relation | contexts | 5497 |
> AccessShareLock | f
> relation | contexts | 5498 |
> AccessShareLock | f
> relation | contexts | 5499 |
> AccessShareLock | f
> relation | contexts | 5500 |
> AccessShareLock | f
> relation | contexts | 5502 |
> AccessShareLock | f
> relation | contexts | 5503 |
> AccessShareLock | f
> relation | contexts | 5504 |
> AccessShareLock | f
> relation | contexts | 5505 |
> AccessShareLock | f
> relation | contexts | 5506 |
> AccessShareLock | f
> relation | contexts | 5507 |
> AccessShareLock | f
> relation | contexts | 5508 |
> AccessShareLock | f
> relation | contexts | 5509 |
> AccessShareLock | f
> relation | contexts | 5510 |
> AccessShareLock | f
> relation | contexts | 5511 |
> AccessShareLock | f
> relation | contexts | 5512 |
> AccessShareLock | f
> relation | contexts | 5515 |
> AccessShareLock | f
> relation | contexts | 5516 |
> AccessShareLock | f
> relation | contexts | 5517 |
> AccessShareLock | f
> relation | contexts | 5518 |
> AccessShareLock | f
> relation | contexts | 5519 |
> AccessShareLock | f
> relation | contexts | 5520 |
> AccessShareLock | f
> relation | contexts | 5521 |
> AccessShareLock | f
> relation | contexts | 5523 |
> AccessShareLock | f
> relation | contexts | 5524 |
> AccessShareLock | f
> relation | contexts_id_key | 18891 |
> AccessShareLock | t
> relation | contexts_pkey | 18891 |
> AccessShareLock | t
> relation | contexts_publication_date_idx | 18891 |
> AccessShareLock | t
> relation | contexts_site_key_ct_id_journal_key | 18891 |
> AccessShareLock | t
> relation | contexts_site_key_ct_type_idx | 18891 |
> AccessShareLock | t
> relation | group_key_idx | 18891 |
> AccessShareLock | t
> relation | parent_key_idx | 18891 |
> AccessShareLock | t
> relation | pg_class | 3911 |
> AccessShareLock | t
> relation | pg_class_oid_index | 3911 |
> AccessShareLock | t
> relation | pg_class_relname_nsp_index | 3911 |
> AccessShareLock | t
> relation | pg_locks | 3911 |
> AccessShareLock | t
> relation | site_key_idx | 18891 |
> AccessShareLock | t
> relation | virtual_ancestor_key_idx | 18891 |
> AccessShareLock | t
> relation | virtual_ancestors | 18891 |
> AccessShareLock | t
> relation | virtual_ancestors_pkey | 18891 |
> AccessShareLock | t
> relation | virtual_context_key_idx | 18891 |
> AccessShareLock | t
> relation | words | 18891 |
> AccessShareLock | t
> relation | words_pkey | 18891 |
> AccessShareLock | t
> relation | words_word | 18891 |
> AccessShareLock | t
Note that pid 3879 can't get the AccessExclusiveLock because pid 18891
is already holding an AccessShareLock. pid 18891 also had a lot of
AccessShareLocks on a bunch of other tables. What is it doing?
Figure out/get rid of that and you're problem will go away.
Erik Jones, Database Administrator
Engine Yard
Support, Scalability, Reliability
866.518.9273 x 260
Location: US/Pacific
IRC: mage2k
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2009-10-07 05:25 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-09-22 16:41 AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks Bryce Nesbitt <bryce2@obviously.com>
2009-09-22 16:55 AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better) Bryce Nesbitt <bryce2@obviously.com>
2009-09-22 17:35 ` Re: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better) Tom Lane <tgl@sss.pgh.pa.us>
2009-09-23 00:10 ` Re: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better) Bryce Nesbitt <bryce2@obviously.com>
2009-10-07 05:25 ` Re: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better) Erik Jones <ejones@engineyard.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox