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