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