Re: Parallel safety of CURRENT_* family

On Thu, Dec 1, 2016 at 3:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Dec 1, 2016 at 2:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> ... well, they would be if we passed down xactStartTimestamp to parallel
>>> workers, but I can't find any code that does that.  In view of the fact that
>>> transaction_timestamp() is marked as parallel-safe, this is a bug in 9.6.
>
>> Yeah.  Do you think we should arrange to pass that down, or change the marking?
>
> We can't fix the marking in existing 9.6 installations, so I think we
> have to pass it down.  (Which would be a better response anyway.)
>
> Having said that, I find myself unable to reproduce a problem.
> This should fail:
>
> regression=# set parallel_setup_cost TO 0;
> SET
> regression=# set parallel_tuple_cost TO 0;
> SET
> regression=# set min_parallel_relation_size TO 0;
> SET
> regression=# set enable_indexscan TO 0;
> SET
> regression=# explain verbose select distinct transaction_timestamp() from tenk1;
>                                       QUERY PLAN
> --------------------------------------------------------------------------------------
>  Unique  (cost=0.00..424.67 rows=1 width=8)
>    Output: (transaction_timestamp())
>    ->  Gather  (cost=0.00..424.67 rows=10000 width=8)
>          Output: (transaction_timestamp())
>          Workers Planned: 2
>          ->  Parallel Seq Scan on public.tenk1  (cost=0.00..410.08 rows=4167 width=8)
>                Output: transaction_timestamp()
> (7 rows)
>
> but it doesn't:
>
> regression=# select distinct transaction_timestamp() from tenk1;
>      transaction_timestamp
> -------------------------------
>  2016-12-01 15:44:12.839417-05
> (1 row)
>
> How is that happening?

Because the table is so small, the leader probably finishes running
the whole plan before the workers finish starting up.

You can see the problem like this, though:

rhaas=# begin;
BEGIN
rhaas=# select transaction_timestamp();    transaction_timestamp
-------------------------------2016-12-01 15:51:14.443116-05
(1 row)

rhaas=# select transaction_timestamp();    transaction_timestamp
-------------------------------2016-12-01 15:51:14.443116-05
(1 row)

rhaas=# select transaction_timestamp();    transaction_timestamp
-------------------------------2016-12-01 15:51:14.443116-05
(1 row)

rhaas=# set force_parallel_mode = true;
SET
rhaas=# select transaction_timestamp();    transaction_timestamp
-------------------------------2016-12-01 15:51:26.603302-05
(1 row)

rhaas=# select transaction_timestamp();    transaction_timestamp
-------------------------------2016-12-01 15:51:27.316032-05
(1 row)

force_parallel_mode causes the whole plan to be run by the worker,
without any participation by the leader.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company