Re: Assert failure in get_baserel_parampathinfo with lateral UNION ALL - Mailing list pgsql-hackers

From wenhui qiu
Subject Re: Assert failure in get_baserel_parampathinfo with lateral UNION ALL
Date
Msg-id CAGjGUALJb3qyXByCdf6p62fq0EbMnOSAkct_Ny0w9=bXnRzdig@mail.gmail.com
Whole thread
In response to Assert failure in get_baserel_parampathinfo with lateral UNION ALL  (Richard Guo <guofenglinux@gmail.com>)
List pgsql-hackers
HI Richard

I think the change to derive `clause_relids` from the child EMs makes sense, especially for the lateral-reference case described in the patch.
One thing I may be missing, though: after replacing `rinfo->clause_relids`, should we also update `rinfo->num_base_rels`?
`make_restrictinfo()` computes `num_base_rels` from the original `clause_relids`, but this patch subsequently replaces `clause_relids` for child clauses.
In cases involving lateral references and nulling outer joins, the two sets can be different, so `num_base_rels` could potentially become stale.
Would it be safer to recompute it from the new `clause_relids` here, using the same definition as in `make_restrictinfo()`?
I am not sure whether there is an invariant elsewhere that makes `num_base_rels` unaffected in these cases. I
t might also be useful to add a regression case specifically covering this metadata, in addition to the existing plan/execution coverage.





Thanks 

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby
Next
From: Michael Paquier
Date:
Subject: Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby