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 18:18:03 |
Message-ID: | CAM3SWZQYm-9qudhiouvrwQ+vh0_6U6U7WS81hzjv=xDXnau-CQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 27, 2013 at 1:09 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> Since it took me a relatively long time to recreate this, it may not
> be trivial to do so. Unless you don't think it's useful to do so, I'm
> going to give this test a full 24 hours, just in case it shows up
> anything else like this.
I see a further, distinct error message this morning:
"ERROR: unrecognized heap_lock_tuple status: 1"
This is a would-be "attempted to lock invisible tuple" error, but with
the error raised by some heap_lock_tuple() call site, unlike the
previous situation where heap_lock_tuple() raised the error directly.
Since with the most recent revision, we handle this (newly possible)
return code in the new ExecLockHeapTupleForUpdateSpec() function, that
just leaves EvalPlanQualFetch() as a plausible place to see it, given
the codepaths exercised in the test case.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2013-11-27 19:24:09 | Re: Status of FDW pushdowns |
Previous Message | Tom Lane | 2013-11-27 18:16:17 | Re: Modify the DECLARE CURSOR command tag depending on the scrollable flag |