Re: transaction safety

From: Jan Wieck <janwieck(at)Yahoo(dot)com>
To: DaVinci <bombadil(at)wanadoo(dot)es>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: transaction safety
Date: 2001-02-14 21:39:44
Message-ID: 200102142139.QAA04640@jupiter.jw.home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

DaVinci wrote:
> On Wed, Feb 14, 2001 at 06:34:01AM -0500, Jan Wieck wrote:
> > The problem is, that a referential integrity constraint needs
> > to ensure that from the moment the constraint got checked
> > until your INSERT got made persistent (COMMIT), nobody else
> > has a chance to kick out the referenced key.
> >
> > Due to the lack of the ability to put a shared row lock with
> > a SELECT, we currently use FOR UPDATE, placing an exclusive
> > lock onto the referenced key.
>
> I understand this but, why then other changes on "aviso" get locked?. My
> first impression is that only referenced keys should be, but not a table
> that references them.

You're right, at the time two FK rows referencing the same PK
get inserted, there is no need to block one of them. Thus,
PostgreSQL *shouldn't* block.

But at the time beeing, the foreign key triggers issue a

SELECT oid FROM <pktable> WHERE <key> = <referenced-value>
FOR UPDATE;

Since both INSERT operations on the FK table do it, the
second one is blocked until COMMIT of the first, releasing
the lock.

What we need is something like

SELECT ...
WITH LOCK;

applying a shared (read) lock of the PK row. In this state,
UPDATE/DELETE to the PK row in question or SELECT ... FOR
UPDATE of that will block, but more SELECT ... WITH LOCK
would be allowed and pass through without blocking.

I don't really want that language construct, since it's not
SQL standard. Maybe it's possible to achieve the same
behaviour with dirty reads or the like. However it's done
finally, it should behave like the above.

>
> If this works so for now, is any plan to change in future?.
>
> > In your case it might help to make the constraints INITIALLY
> > DEFERRED. That causes that the checks are delayed until
> > COMMIT, so it shortens the time the lock is present.
>
> Thanks!. That works fine.

You're welcome.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Patrick Welche 2001-02-14 22:19:14 order of clauses
Previous Message Michael Ansley 2001-02-14 21:24:02 RE: using tables as types in other tables