| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Dmitry Astapov <dastapov(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17619: AllocSizeIsValid violation in parallel hash join |
| Date: | 2022-09-23 23:19:33 |
| Message-ID: | 2169849.1663975173@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> While testing with that module I found another bug: the
> per-participant npages counter was not explicitly initialised to zero
> in sts_initialize(). That wasn't exactly a problem when the code was
> written because new DSM memory is always zeroed and this always
> happens in new DSM memory, but it shows up in this test module because
> it uses palloc() memory instead. It *is* a problem since v14, if you
> use min_dynamic_shared_memory for a pool of recyclable shared memory,
> because then it is not zeroed.
That's a fairly scary observation. What other places are silently
expecting such memory to be zeroed? Do we need to fix things so
that min_dynamic_shared_memory doesn't break this API?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Guo | 2022-09-23 23:54:02 | Re: BUG #17618: unnecessary filter column <> text even after adding index |
| Previous Message | Thomas Munro | 2022-09-23 23:00:00 | Re: BUG #17619: AllocSizeIsValid violation in parallel hash join |