Re: BUG #15217: Valgrind - writing uninitialised byte(s) in FileWrite - Mailing list pgsql-bugs

30.05.2018 08:54, Peter Geoghegan wrote:

This looks like the same harmless warning that we suppressed for
parallel sort in Postgres 11 (see commits 9fafa413ac6 and
de6428afe13). This happens to be a serial sort in Postgres 10, but the
fact that it's still possible there isn't surprising.

What's your work_mem setting? Can you show EXPLAIN ANALYZE output for the query?

Thanks for the answer!

The work_mem setting is 4MB. To get EXPLAIN ANALYZE is rather difficult as I get these errors while running pg_tcpds for hours, but I'll try to catch the query. I will also try to play with work_mem and to apply the aforementioned patches to REL_10_STABLE.

I've managed to reproduce this warning with pg_tpch.
The "problematic" query: https://github.com/tvondra/pg_tpch/blob/master/dss/templates/10.sql
EXPLAIN ANALYZE:
                                                                                                  QUERY PLAN                                                                                                 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=178881.96..178882.01 rows=20 width=202) (actual time=41708.427..41708.994 rows=20 loops=1)
   ->  Sort  (cost=178881.96..179020.08 rows=55249 width=202) (actual time=41706.775..41706.828 rows=20 loops=1)
         Sort Key: (sum((lineitem.l_extendedprice * ('1'::numeric - lineitem.l_discount)))) DESC
         Sort Method: top-N heapsort  Memory: 34kB
         ->  Finalize GroupAggregate  (cost=170313.58..177411.81 rows=55249 width=202) (actual time=27586.165..40109.437 rows=37948 loops=1)
               Group Key: customer.c_custkey, nation.n_name
               ->  Gather Merge  (cost=170313.58..176260.79 rows=46040 width=202) (actual time=27570.718..33645.648 rows=37948 loops=1)
                     Workers Planned: 2
                     Workers Launched: 2
                     ->  Partial GroupAggregate  (cost=169313.56..169946.61 rows=23020 width=202) (actual time=26845.343..34327.273 rows=12649 loops=3)
                           Group Key: customer.c_custkey, nation.n_name
                           ->  Sort  (cost=169313.56..169371.11 rows=23020 width=182) (actual time=26801.917..27406.584 rows=38258 loops=3)
                                 Sort Key: customer.c_custkey, nation.n_name
                                 Sort Method: external sort  Disk: 7016kB
                                 ->  Hash Join  (cost=35074.91..165598.19 rows=23020 width=182) (actual time=8882.471..24071.174 rows=38258 loops=3)
                                       Hash Cond: (customer.c_nationkey = nation.n_nationkey)
                                       ->  Nested Loop  (cost=35073.35..165314.18 rows=23020 width=164) (actual time=8833.355..23146.172 rows=38258 loops=3)
                                             ->  Merge Join  (cost=35072.92..42628.04 rows=23461 width=156) (actual time=8823.262..13619.941 rows=19073 loops=3)
                                                   Merge Cond: (customer.c_custkey = orders.o_custkey)
                                                   ->  Parallel Index Scan using customer_pkey on customer  (cost=0.42..6742.42 rows=62500 width=152) (actual time=13.463..1101.789 rows=50000 loops=3)
                                                   ->  Materialize  (cost=35072.48..35354.01 rows=56306 width=12) (actual time=8795.265..10510.505 rows=57105 loops=3)
                                                         ->  Sort  (cost=35072.48..35213.24 rows=56306 width=12) (actual time=8790.529..9667.322 rows=57105 loops=3)
                                                               Sort Key: orders.o_custkey
                                                               Sort Method: external merge  Disk: 1256kB
                                                               ->  Bitmap Heap Scan on orders  (cost=1197.56..29667.15 rows=56306 width=12) (actual time=273.899..6733.885 rows=57218 loops=3)
                                                                     Recheck Cond: ((o_orderdate >= '1993-07-01'::date) AND (o_orderdate < '1993-10-01 00:00:00'::timestamp without time zone))
                                                                     Rows Removed by Index Recheck: 430095
                                                                     Heap Blocks: exact=15937 lossy=8327
                                                                     ->  Bitmap Index Scan on idx_orders_orderdate  (cost=0.00..1183.49 rows=56306 width=0) (actual time=225.114..225.114 rows=57218 loops=3)
                                                                           Index Cond: ((o_orderdate >= '1993-07-01'::date) AND (o_orderdate < '1993-10-01 00:00:00'::timestamp without time zone))
                                             ->  Index Scan using idx_lineitem_orderkey on lineitem  (cost=0.43..5.19 rows=4 width=20) (actual time=0.372..0.448 rows=2 loops=57218)
                                                   Index Cond: (l_orderkey = orders.o_orderkey)
                                                   Filter: (l_returnflag = 'R'::bpchar)
                                                   Rows Removed by Filter: 2
                                       ->  Hash  (cost=1.25..1.25 rows=25 width=30) (actual time=31.890..31.890 rows=25 loops=3)
                                             Buckets: 1024  Batches: 1  Memory Usage: 10kB
                                             ->  Seq Scan on nation  (cost=0.00..1.25 rows=25 width=30) (actual time=6.582..8.616 rows=25 loops=3)
 Planning time: 689.897 ms
 Execution time: 41835.301 ms
(39 rows)

(The work_mem setting was decreased to 1MB.)
Valgrind logs of the three backends affected are attached.

After applying the changes from 9fafa413ac6 and de6428afe13 I don't see this warning.

Best regards,

------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company