Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: Unexplained lock creating table


  • From: Wes <wespvp(at)syntegra(dot)com>
  • To: <andrew(at)supernews(dot)com>, pgsql general <pgsql-general(at)postgresql(dot)org>
  • Subject: Re: Unexplained lock creating table
  • Date: Sat, 22 Apr 2006 10:05:48 -0500
  • Message-id: <C06FB07C(dot)AFC1%wespvp(at)syntegra(dot)com>

> If this is the first child table of "header", which it presumably is, then
> the pg_class row for "header" has to be updated to set relhassubclass. Since
> you do not commit the create before continuing, this backend continues to
> hold a row lock on the updated, uncommitted pg_class row while you do...

[snip]

> relhassubclass isn't reset to false when all child tables of a parent
> table are removed. So next time through there is no need to update the
> pg_class row for the parent table.
>
> So the simplest workaround is probably to ensure that you create at least
> one partition in each table at the outset, before trying to actually load
> any data.

That's exactly what I was looking for.  Now I know it is safe to do a
'create table', 'drop table' in my database creation script to circumvent
the problem - or to be 100% safe should I not do the 'drop table'?.  I was
afraid I might have to move the 'create table' outside of the transactions.

Many thanks

Wes





Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group