The jdbc inserts go into the main parent table and check constraints
redirect them to child tables.

If I were to drop the rule, that would immediately affect the inserts
and they would go the the parent table. And I cannot lock the parent due
to the problem I mentioned earlier.


-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, September 29, 2006 2:38 PM
To: Sriram Dandapani
Cc: Matthew T. O'Connor; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] autovacuum ignore tables

"Sriram Dandapani" <sdandapani@counterpane.com> writes:
> Real question is: Why do the INSERTS go into wait state as soon as the
> lock table statement is issued on the parent?

If you were just inserting directly into other child tables, a lock on
either the parent or the target child table shouldn't affect them.
I wonder if you are using conditional rules to redirect the inserts,
and the rules include a reference to the target table? If that's the
case, you really need to drop the relevant rule before you remove the
child table, anyway.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

"Sriram Dandapani" <sdandapani@counterpane.com> writes:
> The jdbc inserts go into the main parent table and check constraints
> redirect them to child tables.

A check constraint can't redirect anything. Are you saying that you use
a trigger to try to insert the row into *each* child table, relying on
the constraints to make all except one insert fail? Ugh. You'd do a
lot better to duplicate the partitioning-rule knowledge in the trigger,
and do only one insert that should succeed --- no wasted cycles, and no
need for a subtransaction.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings