Re: Schema variables - new implementation for Postgres 15

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, dean(dot)a(dot)rasheed(at)gmail(dot)com, er(at)xs4all(dot)nl, joel(at)compiler(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Schema variables - new implementation for Postgres 15
Date: 2022-11-04 14:17:18
Message-ID: CAFj8pRBNWSVsJyF2=p9gjOOzn-9pg0dgNUYgswTuK9673V7=rw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

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

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

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2022-11-04 14:28:42 Re: Schema variables - new implementation for Postgres 15
Previous Message Antonin Houska 2022-11-04 14:17:15 Re: WIP: Aggregation push-down - take2