From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Date: | 2013-11-27 04:19:09 |
Message-ID: | CAM3SWZQnjGXQY7++9NwY2ZsVk1o9kKh=2X5S_iG3RXc+rkekkQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 26, 2013 at 1:41 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> Great. I'll let you know what I think.
So having taken a look at what you've done here, some concerns remain.
I'm coming up with a good explanation/test case, which might be easier
than trying to explain it any other way.
There are some visibility-related race conditions even still, with the
same test case as before. It takes a good while to recreate, but can
be done after several hours on an 8 core server under my control:
pg(at)gerbil:~/pgdata$ ls -l -h -a hack_log.log
-rw-rw-r-- 1 pg pg 1.6G Nov 27 05:10 hack_log.log
pg(at)gerbil:~/pgdata$ cat hack_log.log | grep visible
ERROR: attempted to update invisible tuple
ERROR: attempted to update invisible tuple
ERROR: attempted to update invisible tuple
FWIW I'm pretty sure that my original patch has the same bug, but it
hardly matters now.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Haribabu kommi | 2013-11-27 04:27:35 | Re: New option for pg_basebackup, to specify a different directory for pg_xlog |
Previous Message | Shigeru Hanada | 2013-11-27 03:53:12 | Re: Custom Scan APIs (Re: Custom Plan node) |