(Please excuse me if my proposal sounds silly, i'm still not too
advanced in this area...)
On 06/25/2013 10:00 PM, Tom Lane wrote:
> After some contemplation, I think that the most practical way to fix
> this is for deconstruct_recurse and distribute_qual_to_rels to
> effectively move such a qual to the place where it logically belongs;
> that is, rather than processing it when we look at the lower WHERE
> clause, set it aside for a moment and then add it back when looking at
> the ON clause of the appropriate outer join. This should be reasonably
> easy to do by keeping a list of "postponed lateral clauses" while we're
> scanning the join tree.
>
Instead of setting it aside, can we (mis)use placeholder var (PHV), to
ensure
that the WHERE clause is evaluated below the OJ; instead of combining it
with
the ON clause? That would be a special PHV(s) in that it's not actually
referenced from outside the subquery.
Whether I'm right or not, I seem to have found another problem while
trying to enforce such a PHV:
postgres=# SELECT i.*, j.* FROM i LEFT JOIN LATERAL (SELECT COALESCE(i)
FROM j WHERE (i.n = j.n)) j ON true;
The connection to the server was lost. Attempting reset: Failed.
TRAP: FailedAssertion("!(!bms_overlap(min_lefthand, min_righthand))",
File: "initsplan.c", Line: 1043)
LOG: server process (PID 24938) was terminated by signal 6: Aborted
DETAIL: Failed process was running: SELECT i.*, j.* FROM i LEFT JOIN
LATERAL (SELECT COALESCE(i) FROM j WHERE (i.n = j.n)) j ON true;
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back
the current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
FATAL: the database system is in recovery mode
I'm not able to judge right now whether the Assert() statement is the
problem itself or anything
else. You'll probably know better.
(4f14c86d7434376b95477aeeb07fcc7272f4c47d is the last commit in my
environment)
Regards,
Antonin Houska (Tony)