I wrote:
> > One idea that occurs to me is that it might be possible to add to PG
> > some tuple lock modes that are intended to cover updates that don't
> > touch indexed columns. So, say:
> >
> > SHARED NONINDEX - conflicts only with EXCLUSIVE locks
> > SHARED - conflicts with EXCLUSIVE or EXCL
Robert Haas wrote:
[explanation of how Oracle locks on Updates involving foreign keys]
>
> Yeah, that seems odd. I assume they know what they're doing; they're
> Oracle, after all. It does sound, too, like they have column level
> locks based on your comment about "an EXCLUSIVE lock on the modif
On Fri, Feb 5, 2010 at 4:00 AM, Albe Laurenz wrote:
> Robert Haas wrote:
>> Just for kicks I tried this out and the behavior is as the OP
>> describes: after a little poking around, it sees that the INSERT grabs
>> a share-lock on the referenced row so that a concurrent update can't
>> modify the
Robert Haas wrote:
> Just for kicks I tried this out and the behavior is as the OP
> describes: after a little poking around, it sees that the INSERT grabs
> a share-lock on the referenced row so that a concurrent update can't
> modify the referenced column.
>
> It's not really clear how to get ar
On Thu, Feb 4, 2010 at 12:40 AM, wrote:
> I could be wrong in this (if so I know I'll be corrected :-)
>
> but Postgres doesn't need to lock anything for what you are describing.
>
> instead there will be multiple versions of the 'b1' row, one version will be
> deleted, one version that will be k
On Thu, 4 Feb 2010, wangyuxiang wrote:
foreign key constraint lock behavour :
The referenced FK row would be added some exclusive lock , following is the
case:
CREATE TABLE tb_a
(
id character varying(255) NOT NULL,
"name" character varying(255),
b_id character varying(255) NOT NULL,
CON
foreign key constraint lock behavour :
The referenced FK row would be added some exclusive lock , following is the
case:
CREATE TABLE tb_a
(
id character varying(255) NOT NULL,
"name" character varying(255),
b_id character varying(255) NOT NULL,
CONSTRAINT tb_a_pkey PRIMARY KEY (id),
