| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | kuzmin(dot)db4(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19438: segfault with temp_file_limit inside cursor |
| Date: | 2026-03-29 23:41:37 |
| Message-ID: | CAApHDvrdPriH6MO=YGEh9=KVDnDtqZyW4VuRXkmBS8WnRFessA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Mon, 30 Mar 2026 at 04:32, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Here's a fleshed-out version of the requested_size method.
> I noted that AllocSetRealloc needs a defense too, and then
> extended the patch to generation.c and slab.c. bump.c
> doesn't have an issue, and I don't think alignedalloc.c
> needs its own defense either: it can rely on the underlying
> context type.
Thanks for writing that up.
I looked at the code and tested. The only thing that I noted was
GenerationFree(), where we do:
/* Test for previously-freed chunk */
if (unlikely(chunk->requested_size == InvalidAllocSize))
elog(WARNING, "detected double pfree in %s %p",
((MemoryContext) block->context)->name, chunk);
/* Test for someone scribbling on unused space in chunk */
Assert(chunk->requested_size < chunksize);
I expect you've likely thought of this, but if we do spit out the
warning there, then the Assert is definitely going to fail, as
InvalidAllocSize is defined as SIZE_MAX. I don't know if that means
it's worth deviating from the similar WARNINGs you've added and making
that one an ERROR. There's certainly no guarantee with the other
context that we'll not crash sometime very soon after issuing the
warning anyway, so maybe it's fine.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-03-29 23:51:12 | Re: BUG #19438: segfault with temp_file_limit inside cursor |
| Previous Message | David Rowley | 2026-03-29 23:33:57 | Re: BUG #19438: segfault with temp_file_limit inside cursor |