Re: [HACKERS] Segmentation fault when max_parallel degree is very High
On Wed, May 4, 2016 at 11:01 AM, Tom Lane wrote: > Dilip Kumar writes: >> When parallel degree is set to very high say 7, there is a segmentation >> fault in parallel code, >> and that is because type casting is missing in the code.. > > I'd say the cause is not having a sane range limit on the GUC. > >> or corrupt some memory. Need to typecast >> *i * PARALLEL_TUPLE_QUEUE_SIZE --> (Size)i * **PARALLEL_TUPLE_QUEUE_SIZE >> *and >> this will fix > > That might "fix" it on 64-bit machines, but not 32-bit. Yeah, I think what we should do here is use mul_size(), which will error out instead of crashing. Putting a range limit on the GUC is a good idea, too, but I like having overflow checks built into these code paths as a backstop, in case a value that we think is a safe upper limit turns out to be less safe than we think ... especially on 32-bit platforms. I'll go do that, and also limit the maximum parallel degree to 1024, which ought to be enough for anyone (see what I did there?). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Segmentation fault when max_parallel degree is very High
On Wed, May 4, 2016 at 8:31 PM, Tom Lane wrote: > > Dilip Kumar writes: > > When parallel degree is set to very high say 7, there is a segmentation > > fault in parallel code, > > and that is because type casting is missing in the code.. > > I'd say the cause is not having a sane range limit on the GUC. > I think it might not be advisable to have this value more than the number of CPU cores, so how about limiting it to 512 or 1024? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Re: [HACKERS] Segmentation fault when max_parallel degree is very High
Dilip Kumar writes: > When parallel degree is set to very high say 7, there is a segmentation > fault in parallel code, > and that is because type casting is missing in the code.. I'd say the cause is not having a sane range limit on the GUC. > or corrupt some memory. Need to typecast > *i * PARALLEL_TUPLE_QUEUE_SIZE --> (Size)i * **PARALLEL_TUPLE_QUEUE_SIZE *and > this will fix That might "fix" it on 64-bit machines, but not 32-bit. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
