Mark Mielke <mark@mark.mielke.cc> writes:
> # insert into product_image_archived select * from product_image where
> itemno = 'XXXXXX' for update;
> ERROR: cannot extract system attribute from virtual tuple
Hm, on an assert-enabled build this actually crashes :-(. It looks like
I broke the specific case here:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execMain.c.diff?r1=1.280;r2=1.281;f=h
as a result of thinking (in a moment of brain fade) that FOR UPDATE
could only occur within a SELECT. It works in 8.2.
That's fairly easily fixed --- just move the loop that initializes
ctidAttNo out of the operation == CMD_SELECT case --- but looking around
execMain.c I notice that this isn't the only such assumption.
ExecutePlan() thinks that UPDATE and DELETE can't have any FOR UPDATE
clauses. That hasn't been true for awhile; consider
update t1 set ... from (select ... from t2 for update) ss where ...;
CVS HEAD will take this, and silently not do the requested locks :-(
While there are a lot of related cases that we can't currently handle,
this one would work if execMain weren't just blindly ignoring the
possibility. I think we need to rejigger the tests in execMain so
that it either honors the rowmarks or throws error if it can't.
The lack of regression tests covering this area is a bit annoying
at this point. However, it's hard to see how to test FOR UPDATE
until we get some concurrent-sessions support in psql.
regards, tom lane
