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
-
shm_mq: Fix detach race condition.
- 42d7074ebb83 11.0 landed
-
shm_mq: Have the receiver set the sender's less frequently.
- 497171d3e2aa 11.0 cited
-
shm_mq: Reduce spinlock usage.
- 34db06ef9a1d 11.0 cited
-
Report an ERROR if a parallel worker fails to start properly.
- 2badb5afb89c 11.0 cited