Re: COLLATE: Hash partition vs UPDATE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: COLLATE: Hash partition vs UPDATE
Date
Msg-id 30551.1555275007@sss.pgh.pa.us
Whole thread Raw
In response to Re: COLLATE: Hash partition vs UPDATE  (Jesper Pedersen <jesper.pedersen@redhat.com>)
Responses Re: COLLATE: Hash partition vs UPDATE
List pgsql-hackers
Jesper Pedersen <jesper.pedersen@redhat.com> writes:
> Yeah, that works here - apart from an issue with the test case; fixed in
> the attached.

Couple issues spotted in an eyeball review of that:

* There is code that supposes that partsupfunc[] is the last
field of ColumnsHashData, eg

            fcinfo->flinfo->fn_extra =
                MemoryContextAllocZero(fcinfo->flinfo->fn_mcxt,
                                       offsetof(ColumnsHashData, partsupfunc) +
                                       sizeof(FmgrInfo) * nargs);

I'm a bit surprised that this patch manages to run without crashing,
because this would certainly not allocate space for partcollid[].

I think we would likely be well advised to do

-        FmgrInfo    partsupfunc[PARTITION_MAX_KEYS];
+        FmgrInfo    partsupfunc[FLEXIBLE_ARRAY_MEMBER];

to make it more obvious that that has to be the last field.  Or else
drop the cuteness with variable-size allocations of ColumnsHashData.
FmgrInfo is only 48 bytes, I'm not really sure that it's worth the
risk of bugs to "optimize" this.

* I see collation-less calls of the partsupfunc at both partbounds.c:2931
and partbounds.c:2970, but this patch touches only the first one.  How
can that be right?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Should the docs have a warning about pg_stat_reset()?
Next
From: David Rowley
Date:
Subject: Re: partitioning performance tests after recent patches