From: Stephen Frost <sfrost@snowman.net>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Parallel Aggregates for string_agg and array_agg
Date: Mon, 26 Mar 2018 09:20:09 -0400
Message-ID: <20180326132009.GN24540@tamriel.snowman.net> (raw)
In-Reply-To: <CAKJS1f-axkksX3XzduLJuTL=o8CSwf1NaQYO6=iHSXR_B3pCKQ@mail.gmail.com>
References: <CAKJS1f8cB3cc5AK=wPvByhU_jKkgd81iRt2kE6cru8uxx2HCuA@mail.gmail.com>
<c302afa6-6415-27a5-336a-e1d4332fab09@2ndquadrant.com>
<CAKJS1f9xEZdTaBbBEKY+TCKEoSZYaH1oSAtsEJHSYDJCCNnQPQ@mail.gmail.com>
<24abe018-b3c6-2117-b5b9-39e660db00bd@2ndquadrant.com>
<CAKJS1f8LV7AT=AAhdYGKtGrGkSkEgO6C_SW2Ztz1sR3encisqw@mail.gmail.com>
<1b6ee15c-c218-761e-0120-c1ed438e2db2@2ndquadrant.com>
<657be73a-a21d-0ae1-5c62-870afbdfddd4@2ndquadrant.com>
<CAKJS1f-bKAD+s-CJetRQPjmrR-gF-kfvwfzhQm-A0PA-nsr1xw@mail.gmail.com>
<20180326022647.GL24540@tamriel.snowman.net>
<CAKJS1f-axkksX3XzduLJuTL=o8CSwf1NaQYO6=iHSXR_B3pCKQ@mail.gmail.com>
Greetings,
* David Rowley (david.rowley@2ndquadrant.com) wrote:
> On 26 March 2018 at 15:26, Stephen Frost <sfrost@snowman.net> wrote:
> > The header at the top of datumCopy() pretty clearly says that it's for
> > "non-NULL" datums, yet this function seems to be happily ignoring that
> > and just trying to use it to copy everything. Perhaps I'm missing
> > something, but I don't see anything obvious that would lead me to
> > conclude that what's being done here (or in other similar cases in this
> > patch) is acceptable.
>
> Thanks for looking at this.
>
> You're right. I've overlooked this. The code should be checking for
> NULL value Datums there. I've fixed this locally, but on testing, I
> discovered another bug around string_agg. At the moment string_agg's
> transfn only allocates the state when it gets a non-NULL string to
> aggregate, whereas it seems other trans functions which return an
> internal state allocate their state on the first call. e.g.
> int8_avg_accum(). This NULL state is causing the serial function
> segfault on a null pointer dereference. I think the fix is to always
> allocate the state in the transfn, but I just wanted to point this out
> before I go and do that.
Just to be clear- the segfault is just happening with your patch and
you're just contemplating having string_agg always allocate state on the
first call, similar to what int8_avg_accum() does?
If so, then, yes, that seems alright to me.
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
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: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, david.rowley@2ndquadrant.com, tomas.vondra@2ndquadrant.com, andres@anarazel.de
Subject: Re: Parallel Aggregates for string_agg and array_agg
In-Reply-To: <20180326132009.GN24540@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox