public inbox for [email protected]  

help / color / mirror / Atom feed

From: David Rowley <[email protected]>
To: Tom Lane <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: BUG #19438: segfault with temp_file_limit inside cursor
Date: Mon, 30 Mar 2026 14:09:16 +1300
Message-ID: <CAApHDvqv7g3QODYWbaokXrB9eZrY6JkOVO8cO_TXu_PiU_vyOg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<CAApHDvox3Ro8mZJxignuyB-dGXJ9=wQNEkOFni9025GP=rOKkg@mail.gmail.com>
	<[email protected]>
	<CAApHDvrdPriH6MO=YGEh9=KVDnDtqZyW4VuRXkmBS8WnRFessA@mail.gmail.com>
	<[email protected]>
	<CAApHDvpZOCWwSNuBZ4Xg-EcbQ9Bxbk+58AsuE1FCbV5=wyXiqw@mail.gmail.com>
	<[email protected]>

On Mon, 30 Mar 2026 at 13:34, Tom Lane <[email protected]> wrote:
>
> David Rowley <[email protected]> writes:
> > On Mon, 30 Mar 2026 at 12:51, Tom Lane <[email protected]> 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.)

Fair. Maybe worth a short comment in the code to explain why we don't
use the same elevel then? Just considering someone stumbling upon the
variation in the future and reporting or asking why, and us having to
dig up the reason why in the archives to answer them.

Maybe something like this?

/*
* Test for someone scribbling on unused space in chunk.  Small
* overwrites are less likely to cause issues than a double-free, so
* warn for this instead of erroring.
*/

David

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: BUG #19438: segfault with temp_file_limit inside cursor
  In-Reply-To: <CAApHDvqv7g3QODYWbaokXrB9eZrY6JkOVO8cO_TXu_PiU_vyOg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox