Re: [HACKERS] FOR SHARE LOCK clause ?

From: Clark Evans <clark(dot)evans(at)manhattanproject(dot)com>
To: Vadim Mikheev <vadim(at)krs(dot)ru>
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] FOR SHARE LOCK clause ?
Date: 1999-01-05 15:54:29
Message-ID: 369235B5.63CD14A3@manhattanproject.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Ok, in multi-version systems readers never lock
> selected rows and so never block writers. Nice but
> cause problems in some cases: if you want
> to implement referential integrity at the
> application level then you'll have to use
> LOCK TABLE IN SHARE MODE or SELECT FOR UPDATE to
> prevent updation of primary keys etc. Not so good...

I was wondering if there is another perspective
to look upon this problem.

Assertion:

The primary difference between "primary key" and
"unique key" is that primary keys are _never_
updated (during transaction processing) where
unique keys may be.

Question:

It seems that the techinical solution here may
not be better locking, but rather a mechinism
to prevent updates on primary keys unless the
entire table is locked, or some other dramatic
gesture for non-transaction processing.

This leaves the issue of delete looming, so
mabye the suggestion won't help.

Clark

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-01-05 16:02:00 Re: [HACKERS] ./configure: conftest.sh not found
Previous Message Vadim Mikheev 1999-01-05 15:34:19 Re: [HACKERS] FOR SHARE LOCK clause ?