Re: Schema variables - new implementation for Postgres 15

pá 4. 11. 2022 v 15:28 odesílatel Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
napsal:

> > On Fri, Nov 04, 2022 at 03:17:18PM +0100, Pavel Stehule wrote:
> > > I've stumbled upon something that looks weird to me (inspired by the
> > > example from tests):
> > >
> > > =# create variable v2 as int;
> > > =# let v2 = 3;
> > > =# create view vv2 as select coalesce(v2, 0) + 1000 as result
> > >
> > > =# select * from vv2;
> > > result
> > > --------
> > > 1003
> > >
> > > =# set force_parallel_mode to on;
> > > =# select * from vv2;
> > > result
> > > --------
> > > 1000
> > >
> > > In the second select the actual work is done from a worker backend.
> > > Since values of session variables are stored in the backend local
> > > memory, it's not being shared with the worker and the value is not
> found
> > > in the hash map. Does this suppose to be like that?
> > >
> >
> > It looks like a bug, but parallel queries should be supported.
> >
> > The value of the variable is passed as parameter to the worker backend.
> But
> > probably somewhere the original reference was not replaced by parameter
> >
> > On Fri, Nov 04, 2022 at 10:17:13PM +0800, Julien Rouhaud wrote:
> > Hi,
> >
> > There's code to serialize and restore all used variables for parallel
> workers
> > (see code about PARAM_VARIABLE and queryDesc->num_session_variables /
> > queryDesc->plannedstmt->sessionVariables). I haven't reviewed that part
> yet,
> > but it's supposed to be working. Blind guess would be that it's missing
> > something in expression walker.
>
> I see, thanks. I'll take a deeper look, my initial assumption was due to
> the fact that in the worker case create_sessionvars_hashtables is
> getting called for every query.
>

It should be fixed in today's patch

The problem was in missing pushing the hasSessionVariables flag to the
upper subquery in pull_up_simple_subquery.

--- a/src/backend/optimizer/prep/prepjointree.c
+++ b/src/backend/optimizer/prep/prepjointree.c
@@ -1275,6 +1275,9 @@ pull_up_simple_subquery(PlannerInfo *root, Node
*jtnode, RangeTblEntry *rte,
/* If subquery had any RLS conditions, now main query does too */
parse->hasRowSecurity |= subquery->hasRowSecurity;

+ /* If subquery had session variables, now main query does too */
+ parse->hasSessionVariables |= subquery->hasSessionVariables;
+

Thank you for the check and bug report. Your example was added to regress
tests

Regards

Pavel