OOM in hash join

Hi hackers,

Too small value of work_mem cause memory overflow in parallel hash join 
because of too much number batches.
There is the plan:

explain SELECT * FROM solixschema.MIG_50GB_APR04_G1_H a join 
solixschema.MIG_50GB_APR04_G2_H b on a.seq_pk = b.seq_pk join 
solixschema.MIG_50GB_APR04_G3_H c on b.seq_p
k = c.seq_pk join solixschema.MIG_50GB_APR04_G4_H d on c.seq_pk = 
d.seq_pk join solixschema.MIG_50GB_APR04_G5_H e on d.seq_pk = e.seq_pk;
                                                          QUERY PLAN

-----------------------------------------------------------------------------------------------------------------------------
  Gather  (cost=205209076.76..598109290.40 rows=121319744 width=63084)
    Workers Planned: 8
    ->  Parallel Hash Join  (cost=205208076.76..585976316.00 
rows=15164968 width=63084)
          Hash Cond: (b.seq_pk = a.seq_pk)
          ->  Parallel Hash Join  (cost=55621683.59..251148173.17 
rows=14936978 width=37851)
                Hash Cond: (b.seq_pk = c.seq_pk)
                ->  Parallel Hash Join (cost=27797595.68..104604780.40 
rows=15346430 width=25234)
                      Hash Cond: (b.seq_pk = d.seq_pk)
                      ->  Parallel Seq Scan on mig_50gb_apr04_g2_h b  
(cost=0.00..4021793.90 rows=15783190 width=12617)
                      ->  Parallel Hash (cost=3911716.30..3911716.30 
rows=15346430 width=12617)
                            ->  Parallel Seq Scan on mig_50gb_apr04_g4_h 
d  (cost=0.00..3911716.30 rows=15346430 width=12617)
                ->  Parallel Hash  (cost=3913841.85..3913841.85 
rows=15362085 width=12617)
                      ->  Parallel Seq Scan on mig_50gb_apr04_g3_h c  
(cost=0.00..3913841.85 rows=15362085 width=12617)
          ->  Parallel Hash  (cost=102628306.07..102628306.07 
rows=15164968 width=25233)
                ->  Parallel Hash Join (cost=27848049.61..102628306.07 
rows=15164968 width=25233)
                      Hash Cond: (a.seq_pk = e.seq_pk)
                      ->  Parallel Seq Scan on mig_50gb_apr04_g1_h a  
(cost=0.00..3877018.68 rows=15164968 width=12617)
                      ->  Parallel Hash (cost=3921510.05..3921510.05 
rows=15382205 width=12616)
                            ->  Parallel Seq Scan on mig_50gb_apr04_g5_h 
e  (cost=0.00..3921510.05 rows=15382205 width=12616)


work_mem is 4MB and leader + two parallel workers consumes about 10Gb each.
There are 262144 batches:

(gdb) p *hjstate->hj_HashTable
$2 = {nbuckets = 1024, log2_nbuckets = 10, nbuckets_original = 1024,
   nbuckets_optimal = 1024, log2_nbuckets_optimal = 10, buckets = {
     unshared = 0x7fa5d5211000, shared = 0x7fa5d5211000}, keepNulls = 
false,
   skewEnabled = false, skewBucket = 0x0, skewBucketLen = 0, 
nSkewBuckets = 0,
   skewBucketNums = 0x0, nbatch = 262144, curbatch = 86506,
   nbatch_original = 262144, nbatch_outstart = 262144, growEnabled = true,
   totalTuples = 122600000, partialTuples = 61136408, skewTuples = 0,
   innerBatchFile = 0x0, outerBatchFile = 0x0,
   outer_hashfunctions = 0x55ce086a3288, inner_hashfunctions = 
0x55ce086a32d8,
   hashStrict = 0x55ce086a3328, collations = 0x55ce086a3340, spaceUsed = 0,
   spaceAllowed = 8388608, spacePeak = 204800, spaceUsedSkew = 0,
   spaceAllowedSkew = 167772, hashCxt = 0x55ce086a3170,
   batchCxt = 0x55ce086a5180, chunks = 0x0, current_chunk = 0x7fa5d5283000,
   area = 0x55ce085b56d8, parallel_state = 0x7fa5ee993520,
   batches = 0x7fa5d3ff8048, current_chunk_shared = 1099512193024}


The biggest memory contexts are:

ExecutorState: 1362623568
    HashTableContext: 102760280
     HashBatchContext: 7968
    HashTableContext: 178257752
     HashBatchContext: 7968
    HashTableContext: 5306745728
     HashBatchContext: 7968


There is still some gap between size reported by memory context sump and 
actual size of backend.
But is seems to be obvious, that trying to fit in work_mem 
sharedtuplestore creates so much batches, that  them consume much more 
memory than work_mem.