> Using Dirty transaction removing/updating PK could see that concurrent
> xaction attempts to update/insert FK and so would wait for its
commit/abort.
Of course this will require some function that would take tid as one of
arguments, fetch row and check if someone is updating it.
> Jus
> > though constraint triggers should use SnapshotDirty instead of
> > SELECT FOR UPDATE anyway.
> >
> > Did you consider this, Jan?
>
> Whenever the checks are done, the transaction inserting a new
> reference to the key must ensure that this key cannot get
> deleted until it is d
Mikheev, Vadim wrote:
> Try this for both FK tables:
>
> create table tmp2(idx2 int4, col2 int4, constraint
> tmpcon2 foreign key(col2) references tmp1(idx) INITIALLY DEFERRED);
>
> This will defer constraint checks till transaction commit...
> though constraint triggers should use SnapshotDirty i
On Mon, 2 Oct 2000, Rini Dutta wrote:
> When two tables (table2 and table3) have foreign keys
> referring to a common table(table1), I am unable to
> have 2 concurrent transactions - one performing insert
> on table1 and the other on table2, when the records
> being inserted have the same foreign
Try this for both FK tables:
create table tmp2(idx2 int4, col2 int4, constraint
tmpcon2 foreign key(col2) references tmp1(idx) INITIALLY DEFERRED);
This will defer constraint checks till transaction commit...
though constraint triggers should use SnapshotDirty instead of
SELECT FOR UPDATE anyway
