> 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
