| 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: | DFE17B65-07DD-469E-AFEA-536756F9D3B1@phlo.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-12-02 04:22:12 | Re: crash-safe visibility map, take three |
| Previous Message | Itagaki Takahiro | 2010-12-02 03:47:23 | Re: pg_execute_from_file review |