select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

Thomas Munro <thomas.munro@enterprisedb.com>

From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-03-04T02:20:57Z
Lists: pgsql-hackers
Hi,

I saw a one-off failure like this:

                                  QUERY PLAN
  --------------------------------------------------------------------------
   Aggregate (actual rows=1 loops=1)
!    ->  Nested Loop (actual rows=98000 loops=1)
           ->  Seq Scan on tenk2 (actual rows=10 loops=1)
                 Filter: (thousand = 0)
                 Rows Removed by Filter: 9990
!          ->  Gather (actual rows=9800 loops=10)
                 Workers Planned: 4
                 Workers Launched: 4
                 ->  Parallel Seq Scan on tenk1 (actual rows=1960 loops=50)
--- 485,495 ----
                                  QUERY PLAN
  --------------------------------------------------------------------------
   Aggregate (actual rows=1 loops=1)
!    ->  Nested Loop (actual rows=97984 loops=1)
           ->  Seq Scan on tenk2 (actual rows=10 loops=1)
                 Filter: (thousand = 0)
                 Rows Removed by Filter: 9990
!          ->  Gather (actual rows=9798 loops=10)
                 Workers Planned: 4
                 Workers Launched: 4
                 ->  Parallel Seq Scan on tenk1 (actual rows=1960 loops=50)


Two tuples apparently went missing.

Similar failures on the build farm:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=okapi&dt=2018-03-03%2020%3A15%3A01
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=locust&dt=2018-03-03%2018%3A13%3A32
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2018-03-03%2017%3A55%3A11

Could this be related to commit
34db06ef9a1d7f36391c64293bf1e0ce44a33915 or commit
497171d3e2aaeea3b30d710b4e368645ad07ae43?

-- 
Thomas Munro
http://www.enterprisedb.com


Commits

  1. shm_mq: Fix detach race condition.

  2. shm_mq: Have the receiver set the sender's less frequently.

  3. shm_mq: Reduce spinlock usage.

  4. Report an ERROR if a parallel worker fails to start properly.