From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | bernddorn(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17227: segmentation fault with jsonb_to_recordset |
Date: | 2021-10-13 22:58:10 |
Message-ID: | 709405.1634165890@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I wrote:
> Apparently this idea failed to account for subexpressions pulled up
> during later processing. Back to the drawing board.
After further study of 7266d0997, it seems we could fix this by
the expedient of repeating eval_const_expressions on a function
RTE whenever it contains LATERAL references. The code already
understood that lateral join aliases were trouble, but it didn't
account for the case of subexpressions inserted by subquery
pullup (which'd have to have been lateral refs originally).
The whole thing makes me itch a little bit, because this logic is
assuming that eval_const_expressions is idempotent, something
we can't test very well and (AFAIR) are not assuming anywhere else.
If somebody made some sub-case not idempotent, we'd not notice until
that case got used in a lateral function RTE. That could be a long
time, as evidenced by the fact that this bug went undetected for a
year since v13 release. However, we had that assumption in the code
7266d0997 replaced too, so this isn't adding any real new risk.
I looked briefly at whether the planner's preprocessing steps
could be re-ordered to eliminate the need for sometimes reprocessing
function RTEs. It looks like it'd be a mess though, a conclusion
I think I also reached before committing 7266d0997.
Anyway, unless somebody has a better idea, I'll flesh out the
attached with a test case and push it.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
lateral-function-pullup-bug-wip.patch | text/x-diff | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2021-10-14 00:36:55 | Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES |
Previous Message | Peter Geoghegan | 2021-10-13 21:09:48 | Re: BUG #17212: pg_amcheck fails on checking temporary relations |