Tom Lane wrote:
This isn't going to be changed, because the likely direction of future
development is that the planner will start making use of constraints
even for SELECT queries. This means that a DROP CONSTRAINT operation
could invalidate the plan of a SELECT query, so the locking will be
ess
Scott Marlowe wrote:
What if, a minute or two after the drop contraint, you issue a rollback?
After the DROP CONSTRAINT I insert 4 million rekords into the TABLE b.
After the inserts I remake the dropped constraints, and commit the
transaction (P1). This solution is faster then the conventio
Atesz <[EMAIL PROTECTED]> writes:
> My question: Why need this strict locking?
> In my opinion there isn't exclusion between the DROP CONSTRAINT and the
> SELECT.
This isn't going to be changed, because the likely direction of future
development is that the planner will start making use of const
On Wed, 2006-10-18 at 09:24, Atesz wrote:
> Hi!
>
> I have a problem with ACCESS EXCLUSIVE lock when I drop a reference in
> transaction. I have 2 tables:
> create table a(id SERIAL primary key);
> create table b(id SERIAL primary key references a(id));
>
> After that I have 2 processes: P1,
Hi!
I have a problem with ACCESS EXCLUSIVE lock when I drop a reference in
transaction. I have 2 tables:
create table a(id SERIAL primary key);
create table b(id SERIAL primary key references a(id));
After that I have 2 processes: P1, P2
In P1:
begin;
ALTER TABLE b DROP CONSTRAINT b_id_fke
