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...
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-12-02 04:22:12|
|Subject: Re: crash-safe visibility map, take three|
|Previous:||From: Itagaki Takahiro||Date: 2010-12-02 03:47:23|
|Subject: Re: pg_execute_from_file review|