Re: BUG #19438: segfault with temp_file_limit inside cursor

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
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-30 00:34:48
Message-ID: 1886754.1774830888@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Mon, 30 Mar 2026 at 12:51, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Seems like a reasonable answer. What do you think of making the
>> double-free cases ERRORs across the board? If we don't error out,
>> there will likely be cascading problems in all the mcxt types not
>> just this one.

> I think it's a good idea. It might slightly increase the chances that
> we get a report about an issue. I suppose the logic in deciding which
> elevel to make it could be applied about equally to the sentinel byte
> check as well. Maybe that should also be an error for the same reason.

I thought about that, but it's been a WARNING for a long time and I'm
hesitant to change that. We've seen many cases where scribbling one
or two bytes past the end of the requested size doesn't actually cause
fatal problems, because that was padding or unused space anyway.
Double frees are in a different category: if we let one happen,
it's pretty much guaranteed to cause hard-to-decipher problems down
the road. (The fact that that didn't happen in the particular case
reported here doesn't mean it's usually okay.)

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Rowley 2026-03-30 01:09:16 Re: BUG #19438: segfault with temp_file_limit inside cursor
Previous Message David Rowley 2026-03-30 00:15:56 Re: BUG #19438: segfault with temp_file_limit inside cursor