Re: Failed assertion root->hasLateralRTEs on initsplan.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: emre(at)hasegeli(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Failed assertion root->hasLateralRTEs on initsplan.c
Date: 2014-01-07 18:15:49
Message-ID: 17284.1389118549@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Emre Hasegeli <emre(at)hasegeli(dot)com> writes:
> I get assertion failure on initsplan.c line 1325 while executing following query
> on HEAD (edc43458d797a5956f4bf39af18cf62abb0077db). It works fine
> without --enable-cassert.

> update subscriber set properties = hstore(a) from (select firstname,
> lastname from player where player.id = subscriber.id) as a;

Hm, AFAICS this query should absolutely *not* work; the reference to
subscriber.id inside the sub-select is illegal. It might be legal with
LATERAL, but not otherwise. So I think this is a parser bug, and there's
nothing wrong with the planner's Assert. 9.2 and earlier throw the
error I'd expect, so probably something in the LATERAL patches broke
this case; will look.

The next question is if we should allow it with LATERAL. That would
essentially be treating "subscriber" as having implicitly appeared at the
start of the FROM list, which I guess is all right ... but does anyone
want to argue against it? I seem to recall some old discussions about
allowing the update target to be explicitly shown in FROM, in case you
wanted say to left join it against something else. Allowing this implicit
appearance might limit our options if we ever get around to trying to do
that. On the other hand, those discussions were a long time back, so
maybe it'll never happen anyway.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2014-01-07 19:11:33 Re: Re: How to reproduce serialization failure for a read only transaction.
Previous Message Dimitri Fontaine 2014-01-07 17:26:28 Re: Fixing pg_basebackup with tablespaces found in $PGDATA