<!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(dot)1253640939(at)sss(dot)pgh(dot)pa(dot)us" type="cite">
<pre wrap="">Bryce Nesbitt <a class="moz-txt-link-rfc2396E" href="mailto:bryce2(at)obviously(dot)com"><bryce2(at)obviously(dot)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>