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: 2006-04-22 15:05:48
Message-ID: C06FB07C.AFC1%wespvp@syntegra.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Dave Page 2006-04-22 15:30:21 Re: Debian package for freeradius_postgresql module
Previous Message Martijn van Oosterhout 2006-04-22 14:09:34 Re: Debian package for freeradius_postgresql module