Re: Parallelized polymorphic aggs, and aggtype vs aggoutputtype

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallelized polymorphic aggs, and aggtype vs aggoutputtype
Date: 2016-06-22 23:22:16
Message-ID: 10050.1466637736@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> I've attached my proposed patch for the user defined aggregate docs.

I whacked this around some more and pushed it.

While working on that, I noticed what seems to me to be a minor bug.
The behavior that I'd expect (and that I documented) for a deserialization
function is that it just allocates its result in the current, short-lived
memory context, since it will be the combine function's responsibility to
merge that into the long-lived transition state. But it looks to me like
the deserialization functions in numeric.c are allocating their results
in the aggregate context, which will mean a leak. (For example,
numeric_avg_deserialize creates its result using makeNumericAggState
which forces the result into the agg context.)

Now this leak isn't going to be real significant unless we accumulate a
whole lot of partial results in one query, which would be unusual and
maybe even impossible in the current parallel-query environment. But it
still seems wrong. Please check, and submit a patch if I'm right about
what's happening.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2016-06-22 23:50:57 Re: sslmode=require fallback
Previous Message Craig Ringer 2016-06-22 22:43:58 Re: how is the WAL receiver process stopped and restarted when the network connection is broken and then restored?