On Mon, Jan 23, 2017 at 12:45 AM, Amit Langote
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 m
On 2017/01/21 9:01, Tom Lane wrote:
> Robert Haas writes:
>> The difference is that those other equalBLAH functions call a
>> carefully limited amount of code whereas, in looking over the
>> backtrace you sent, I realized that equalPartitionDescs is calling
>> partition_bounds_equal which does thi
Robert Haas writes:
> The difference is that those other equalBLAH functions call a
> carefully limited amount of code whereas, in looking over the
> backtrace you sent, I realized that equalPartitionDescs is calling
> partition_bounds_equal which does this:
>cmpval =
> Dat
On Fri, Jan 20, 2017 at 4:30 PM, Tom Lane wrote:
> Stephen Frost writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> Robert Haas writes:
Hmm. That's bad. I kind of wonder how sane it is to think that we
can invoke SQL-callable functions during a relcache reload,
>
>>> You're doing
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Robert Haas writes:
>>> Hmm. That's bad. I kind of wonder how sane it is to think that we
>>> can invoke SQL-callable functions during a relcache reload,
>> You're doing WHAT?
> Uh. +1.
Now that I've calmed down a bit: the ri
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > Hmm. That's bad. I kind of wonder how sane it is to think that we
> > can invoke SQL-callable functions during a relcache reload, because
> > couldn't we be processing an invalidation in the context of an aborted
> > transaction?
>
Robert Haas writes:
> Hmm. That's bad. I kind of wonder how sane it is to think that we
> can invoke SQL-callable functions during a relcache reload, because
> couldn't we be processing an invalidation in the context of an aborted
> transaction?
You're doing WHAT?
regar
On Fri, Jan 20, 2017 at 8:09 AM, Tom Lane wrote:
> skink has been unhappy since commit d26fa4f went in, but I think
> that just exposed a pre-existing bug. Running valgrind here
> duplicates the failure:
>
> ==00:00:02:01.653 16626== Conditional jump or move depends on uninitialised
> value(s)
>
skink has been unhappy since commit d26fa4f went in, but I think
that just exposed a pre-existing bug. Running valgrind here
duplicates the failure:
==00:00:02:01.653 16626== Conditional jump or move depends on uninitialised
value(s)
==00:00:02:01.653 16626==at 0x4BDF6B: btint4cmp (nbtcompar
