Обсуждение: BUG #3479: contraint exclusion and locks
The following bug has been logged online: Bug reference: 3479 Logged by: Tiago Jacobs Email address: tiago@mdtestudio.com.br PostgreSQL version: 8.2.4 Operating system: Linux 2.6.21.5 Description: contraint exclusion and locks Details: Hi People! Connection #1 create table tab (dt_tab date); create table tab_2 () inherits (tab); create table tab_1 () inherits (tab); alter table tab_2 add constraint constraint_x check (dt_tab >= '20070701'); alter table tab_2 add constraint constraint_y check (dt_tab <= '20070731'); alter table tab_1 add constraint constraint_x check (dt_tab >= '20070601'); alter table tab_1 add constraint constraint_y check (dt_tab <= '20070630'); explain select * from tab where dt_tab = '20070705'; >"Result (cost=0.00..73.50 rows=22 width=4)" >" -> Append (cost=0.00..73.50 rows=22 width=4)" >" -> Seq Scan on tab (cost=0.00..36.75 rows=11 width=4)" >" Filter: (dt_tab = '2007-07-05'::date)" >" -> Seq Scan on tab_2 tab (cost=0.00..36.75 rows=11 width=4)" >" Filter: (dt_tab = '2007-07-05'::date)" Connection #2 begin; lock table tab_1 in exclusive mode; TrUNCATE TABLE tab_1; Connection #1 explain select * from tab where dt_tab = '20070705' oh-ow... It waits while the table (That is not used) is locked. Even that the final plan dont use tab_2007_07, it wait for unlock of table for make the plan. So, if I`m running a VACUUM on specific table, all the querys on the "master" table don't work. Best Regards, Tiago
"Tiago Jacobs" <tiago@mdtestudio.com.br> writes: > oh-ow... It waits while the table (That is not used) is locked. > > Even that the final plan dont use tab_2007_07, it wait for unlock of table > for make the plan. Well one of the reasons exclusive locks are taken are to make changes to constraints. > So, if I`m running a VACUUM on specific table, all the querys on the > "master" table don't work. VACUUM doesn't take an exclusive lock. VACUUM is designed to be run regularly without interfering with full use of the table. You're not running VACUUM FULL are you? That's much more intrusive and shouldn't be needed in regular operation. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
"Tiago Jacobs" <tiago@mdtestudio.com.br> writes:
> oh-ow... It waits while the table (That is not used) is locked.
This is not a bug. It has to inspect the table to find out that
there is a constraint.
regards, tom lane
Tom and Gregory. U're right! The problem is
that we're using constraints for partitioned tables and by definition,
a partition never, absolutely never, can affect the entire system.
But I think that we have nothing to do about this. There are plans to
another kind of partitioning? If yes, I would like to contribute. If
not, i`m okay.
Just tried to help.
Okay, sorry about take your time for it.
Tiago
Tom Lane escreveu:
"Tiago Jacobs" <tiago@mdtestudio.com.br> writes:
oh-ow... It waits while the table (That is not used) is locked.
This is not a bug. It has to inspect the table to find out that
there is a constraint.
regards, tom lane
Gregory Stark escreveu:
"Tiago Jacobs" <tiago@mdtestudio.com.br> writes:
oh-ow... It waits while the table (That is not used) is locked.
Even that the final plan dont use tab_2007_07, it wait for unlock of table
for make the plan.
Well one of the reasons exclusive locks are taken are to make changes to
constraints.
So, if I`m running a VACUUM on specific table, all the querys on the
"master" table don't work.
VACUUM doesn't take an exclusive lock. VACUUM is designed to be run regularly
without interfering with full use of the table.
You're not running VACUUM FULL are you? That's much more intrusive and
shouldn't be needed in regular operation.
"Tiago Daniel Jacobs" <tiago@mdtestudio.com.br> writes: > <small><font face="Arial">Tom and Gregory. U're right! The problem is > that we're using constraints for partitioned tables and by definition, > a partition never, absolutely never, can affect the entire system.<br> > <br> > But I think that we have nothing to do about this. There are plans to > another kind of partitioning? If yes, I would like to contribute. If > not, i`m okay. <br> There are lots of ideas of where to go with partitioning including possibly ditching the use of constraints. But I don't think there's any settled plans yet. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
On Mon, 2007-07-23 at 11:46 -0300, Tiago Daniel Jacobs wrote: > Tom and Gregory. U're right! The problem is that we're using > constraints for partitioned tables and by definition, a partition > never, absolutely never, can affect the entire system. > Yeh, the problem is that partitioning uses additional information to avoid reading data. The additional information and the actual data need to be kept in step, so at some point we may need to re-write that data and we'll always need a lock to do that. So whether we use constraints, segment headers or what have you, there'll still be a need to lock and be locked out. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
Hi, why if I REINDEX a inherited table, all tables are locked?
Example:
[conn #1] REINDEX TABLE month_a;
[conn #2] PREPARE updt as update month_b set col_a=1 where col_b=$1;
The query on conn#2 waits.
regards,
Tiago
Tom Lane escreveu:
"Tiago Jacobs" <tiago@mdtestudio.com.br> writes:
oh-ow... It waits while the table (That is not used) is locked.
This is not a bug. It has to inspect the table to find out that
there is a constraint.
regards, tom lane