Re: foreign key introduces unnecessary locking ?

From: "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>
To: "Jan Wieck" <janwieck(at)Yahoo(dot)com>
Cc: "'Rini Dutta'" <rinid(at)rocketmail(dot)com>, <pgsql-sql(at)hub(dot)org>, <pgsql-hackers(at)hub(dot)org>, "Jan Wieck \\(E-mail\\)" <janwieck(at)Yahoo(dot)com>
Subject: Re: foreign key introduces unnecessary locking ?
Date: 2000-10-23 21:29:02
Message-ID: 006c01c03d38$43f58280$b57a30d0@sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

> 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.

> Just like now same row writers wait for each other.

Vadim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dominic J. Eidson 2000-10-23 22:00:48 Re: Great Bridge is hiring!
Previous Message Vadim Mikheev 2000-10-23 21:23:06 Re: [HACKERS] Re: pgsql/src/test/regress/expected (plpgsql.out inet.out foreign_key.out errors.out)

Browse pgsql-sql by date

  From Date Subject
Next Message The Hermit Hacker 2000-10-23 23:52:46 Re: Postgresql Site Search
Previous Message Josh Berkus 2000-10-23 19:04:50 Re: SQL