Horton

Re: PostgreSQL crashes with SIGSEGV

Michael Paquier <michael.paquier@gmail.com>

View thread View on postgr.es
From: Michael Paquier <michael.paquier@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Andreas Seltenreich <andreas.seltenreich@credativ.de>, Bernd Helmle <mailings@oopsware.de>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-12-17T10:46:17Z
Lists: pgsql-bugs, pgsql-hackers 
On Sun, Dec 17, 2017 at 10:40 AM, Peter Geoghegan <pg@bowt.ie> wrote:
> On Thu, Dec 14, 2017 at 5:58 PM, Peter Geoghegan <pg@bowt.ie> wrote:
>> The ambiguity about who owns the tuple memory when is the basic
>> problem, once again. One could argue that it's the caller's fault for
>> not knowing to not pfree() the tuple after tuplesort_end() is called,
>> but I don't buy that because it seems like an undue burden on callers
>> to do that. It seems okay to either provide a very weak, simple
>> guarantee about tuple memory lifetime, or very strong simple guarantee
>> about tuple memory lifetime. That's what routines like
>> tuplesort_gettupleslot() and tuplesort_getindextuple() should limit
>> their contracts to -- we've had enough problems in this area over the
>> years that that seems pretty clear to me.
>>
>> ISTM that an appropriate fix is one that results in having
>> tuplesort_gettupleslot() tuple memory that is *consistently* allocated
>> within caller's own memory context, at least on versions prior to
>> Postgres 10 (it's a bit more complicated in Postgres 10).
>
> This took longer than expected. Attached patch, which targets 9.6,
> shows what I have in mind. I'm going on vacation shortly, but wanted
> to post this patch before I leave. It could definitely use some more
> testing, since it was written under time pressure. I expect to be back
> early in the new year, so if someone feels like taking this off my
> hands, they're more than welcome to do so.

Could you add that to the next commit fest registered as a bug fix? We
don't want to lose track of that and this should be reviewed.
-- 
Michael

Commits

  1. Fix actual and potential double-frees around tuplesort usage.

  2. Allow the built-in ordered-set aggregates to share transition state.

  3. Avoid integer overflow while sifting-up a heap in tuplesort.c.

  4. Allow avoiding tuple copy within tuplesort_gettupleslot().

  5. Remove should_free arguments to tuplesort routines.

  6. Fix use-after-free around DISTINCT transition function calls.

  7. Reuse abbreviated keys in ordered [set] aggregates.