Re: [HACKERS] proposal: schema variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] proposal: schema variables
Date
Msg-id CAFj8pRDREykg0hnMBkryBmSTtqEs9QUKUp_447_F5P1j8bkH1w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] proposal: schema variables  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: [HACKERS] proposal: schema variables
List pgsql-hackers


út 4. 9. 2018 v 9:21 odesílatel Dean Rasheed <dean.a.rasheed@gmail.com> napsal:
AFAICS this patch does nothing to consider parallel safety -- that is,
as things stand, a variable is allowed in a query that may be
parallelised, but its value is not copied to workers, leading to
incorrect results. For example:

create table foo(a int);
insert into foo select * from generate_series(1,1000000);
create variable zero int;
let zero = 0;

explain (costs off) select count(*) from foo where a%10 = zero;

                  QUERY PLAN
-----------------------------------------------
 Finalize Aggregate
   ->  Gather
         Workers Planned: 2
         ->  Partial Aggregate
               ->  Parallel Seq Scan on foo
                     Filter: ((a % 10) = zero)
(6 rows)

select count(*) from foo where a%10 = zero;

 count
-------
 38037    -- Different random result each time, should be 100,000
(1 row)

Thoughts?

This issue should be fixed in attached patch (and more others).

The code is more cleaner now, there are more tests, and documentation is mostly complete. I am sorry - my English is not good.
New features:

o ON COMMIT DROP and ON TRANSACTION END RESET -- remove temp variable on commit, reset variable on transaction end (commit, rollback)
o LET var = DEFAULT -- reset specified variable

Regards

Pavel


Regards,
Dean
Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Logical replication to partitioned subscriber
Next
From: Tom Lane
Date:
Subject: Re: pg_dump test instability