| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
| Date: | 2014-01-19 06:26:25 |
| Message-ID: | CAM3SWZRfFjXwEHDBqksW7ebri8LH-WoXUzXQp895SYSNxx6msA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jan 18, 2014 at 7:49 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> Personally, I favor just making "case HeapTupleSelfUpdated:" within
> the patch's ExecLockHeapTupleForUpdateSpec() function complain when
> "hufd.cmax == estate->es_output_cid)" (currently there is a separate
> complaint, but only when those two variables are unequal). That's
> probably almost perfect in practice.
Actually, there isn't really a need to do so, since I believe in
practice the tuple locked will always be instantaneously invisible
(when we have the scope to avoid this "updated the tuple twice in the
same command" problem by forbidding it in the style of SQL MERGE).
However, I think I'm going to propose that we still do something in
the ExecLockHeapTupleForUpdateSpec() HeapTupleSelfUpdated handler (in
addition to HeapTupleInvisible), because that'll still be illustrative
dead code.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2014-01-19 06:41:46 | Re: array_length(anyarray) |
| Previous Message | Jov | 2014-01-19 05:00:13 | Re: improve the help message about psql -F |