Skip site navigation (1) Skip section navigation (2)

Re: improving foreign key locks

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: improving foreign key locks
Date: 2010-12-02 03:53:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Dec2, 2010, at 00:59 , Jim Nasby wrote:
> On Dec 1, 2010, at 11:09 AM, Florian Pflug wrote:
>> An UPDATE on such a SHARE locked row would be allowed despite the lock if it only changed columns not mentioned by any unique index.
> On a side-note, by "changed columns" do you mean the column appeared in the UPDATE statement, or the data actually changed? I suspect the former might be easier to implement, but it's really going to fsck with some applications (Rails is one example that comes to mind).

The most sensible thing to do is probably to make it mean "columns whose new value's binary representation differs from the old value's binary representation". That is also what is checked for HOT updated I believe, though I didn't recheck...

best regards,
Florian Pflug

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-12-02 04:22:12
Subject: Re: crash-safe visibility map, take three
Previous:From: Itagaki TakahiroDate: 2010-12-02 03:47:23
Subject: Re: pg_execute_from_file review

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group