Re: [HACKERS] Valgrind-detected bug in partitioning code - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Valgrind-detected bug in partitioning code
Date
Msg-id CA+Tgmoa98FfK6y3VQfcmDgDFk3gLvi5Aihghn2G5zymrfz4bWg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Valgrind-detected bug in partitioning code  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
On Mon, Jan 23, 2017 at 12:45 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> Sorry for jumping in late.  Attached patch replaces the call to
> partitioning-specific comparison function by the call to datumIsEqual().
> I wonder if it is safe to assume that datumIsEqual() would return true for
> a datum and copy of it made using datumCopy().  The latter is used to copy
> a single datum from a bound's Const node (what is stored in the catalog
> for every bound).

Thanks, committed.  I expanded the comment in partition.c because I
think you missed the other rationale for doing it this way, which is
that the partitioning operator might ignore some "unimportant" changes
(e.g. for numeric, the difference between 1.0 and 1.00) but for this
purpose it's better to update the relcache if there is *any* change.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Declarative partitioning vs. BulkInsertState
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] [PATCH] Generic type subscription