Re: BUG #3479: contraint exclusion and locks - Mailing list pgsql-bugs

From Tiago Daniel Jacobs
Subject Re: BUG #3479: contraint exclusion and locks
Date
Msg-id 46A4BF47.1080004@mdtestudio.com.br
Whole thread Raw
In response to Re: BUG #3479: contraint exclusion and locks  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: BUG #3479: contraint exclusion and locks
Re: BUG #3479: contraint exclusion and locks
List pgsql-bugs
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.

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #3479: contraint exclusion and locks
Next
From: Gregory Stark
Date:
Subject: Re: BUG #3479: contraint exclusion and locks