Re: Schema variables - new implementation for Postgres 15 - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Schema variables - new implementation for Postgres 15
Date
Msg-id 20221104141713.4y3dpmlmp73zkwzb@jrouhaud
Whole thread Raw
In response to Re: Schema variables - new implementation for Postgres 15  (Dmitry Dolgov <9erthalion6@gmail.com>)
List pgsql-hackers
Hi,

On Fri, Nov 04, 2022 at 03:07:48PM +0100, Dmitry Dolgov wrote:
> > On Fri, Nov 04, 2022 at 05:58:06AM +0100, Pavel Stehule wrote:
> > Hi
> >
> > fix clang warning
>
> 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?

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.



pgsql-hackers by date:

Previous
From: David Christensen
Date:
Subject: Re: [PATCH] Teach pg_waldump to extract FPIs from the WAL
Next
From: Antonin Houska
Date:
Subject: Re: WIP: Aggregation push-down - take2