Re: 9.0.X FOR UPDATE|SHARE on Sub-Query Causes "cannot extract system attribute from virtual tuple" if Sub-Query Returns Records (BUG)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David Johnston" <polobo(at)yahoo(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: 9.0.X FOR UPDATE|SHARE on Sub-Query Causes "cannot extract system attribute from virtual tuple" if Sub-Query Returns Records (BUG)
Date: 2011-02-10 17:10:47
Message-ID: 17627.1297357847@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"David Johnston" <polobo(at)yahoo(dot)com> writes:
>> From your commit notes:

> "This wasn't a problem before 9.0 because we didn't support FOR UPDATE
> below the top query level..."

> FWIW I had been using a sub-query FOR UPDATE in one of my key queries (one
> that was called multiple times per second) and relied upon the FOR UPDATE to
> avoid having the same record "dispatched" multiple times. It worked just
> fine in 8.2.X and 8.4.X - supported or not.

Yeah, what that actually meant was that we didn't support FOR UPDATE
below the top level of the query *as executed*. The optimizer used to
flatten subqueries containing FOR UPDATE if it could (and fail if it
couldn't). 9.0 changes that behavior because it led to FOR UPDATE
locking getting applied in unexpected/unpredictable ways in more complex
queries, eg joins.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Samuel Gilbert 2011-02-10 17:13:33 COPY statement REAL vs VARCHAR precision issue
Previous Message Jens Sauer 2011-02-10 16:16:33 Re: fulltext search and hunspell