Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
От | Peter Geoghegan |
---|---|
Тема | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Дата | |
Msg-id | CAM3SWZQYm-9qudhiouvrwQ+vh0_6U6U7WS81hzjv=xDXnau-CQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE (Peter Geoghegan <pg@heroku.com>) |
Список | pgsql-hackers |
On Wed, Nov 27, 2013 at 1:09 AM, Peter Geoghegan <pg@heroku.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
В списке pgsql-hackers по дате отправления: