This new limit affects both the max_parallel_degree GUC and the
parallel_degree reloption. There may some day be a use case for using
more than 1024 CPUs for a single query, but that's surely not the case
right now. Not only do not very many people have that many CPUs, but
the code hasn't been tested at that kind of scale and is very unlikely
to perform well, or even work at all, without a lot more work. The
issue addressed by commit
06bd458cb812623c3f1fdd55216c4c08b06a8447 is
probably just one problem of many.
The idea of a more reasonable limit here was suggested by Tom Lane;
the value of 1024 was suggested by Amit Kapila.
RELOPT_KIND_HEAP,
AccessExclusiveLock
},
- -1, 0, MAX_BACKENDS
+ -1, 0, 1024
},
/* list terminator */
NULL
},
&max_parallel_degree,
- 2, 0, MAX_BACKENDS,
+ 2, 0, 1024,
NULL, NULL, NULL
},