> 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.
