Re: Segmentation fault when max_parallel degree is very High
От | Robert Haas |
---|---|
Тема | Re: Segmentation fault when max_parallel degree is very High |
Дата | |
Msg-id | CA+TgmoYKGcf5k1Xt-Ev7mCCP+4Cnmchn4FFSYaykKV+6RvFxnA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Segmentation fault when max_parallel degree is very High (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, May 4, 2016 at 11:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Dilip Kumar <dilipbalaut@gmail.com> writes: >> When parallel degree is set to very high say 70000, 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
В списке pgsql-hackers по дате отправления: