Re: [HACKERS] putting CHECK_FOR_INTERRUPTS in - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: [HACKERS] putting CHECK_FOR_INTERRUPTS in
Date
Msg-id 200607300148.k6U1mUN00127@momjian.us
Whole thread Raw
In response to Re: [HACKERS] putting CHECK_FOR_INTERRUPTS in  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Are we done with the sort interrupt issue mentioned in the subject line,
> > and the issue outlined below?
>
> I'm inclined not to apply the proposed patch (adding
> CHECK_FOR_INTERRUPTS) because of the risk of memory leakage inside
> qsort.  OTOH you could argue that there's an unfixable risk of memory
> leakage there anyway, because it's always possible that the invoked
> datatype comparison routine exits with elog(ERROR) for some reason,
> or even contains a CHECK_FOR_INTERRUPTS call itself.  Comments?

OK, we do check somewhere during sorting, I assume.  I can't imagine a
single qsort() call taking all that long because we do them in batches
anyway.

> As for the question of whether we should try to detoast sort keys before
> sorting, I'd suggest adding that to TODO.  Investigating whether this
> would be a good idea will take more time than we have for 8.2, so it's
> gonna have to wait for a future cycle.

Added to TODO:

    * Consider detoasting keys before sorting

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] pg_regress breaks on msys
Next
From: Bruce Momjian
Date:
Subject: Re: PATCH to allow concurrent VACUUMs to not lock each