I wrote:
> I'm inclined to just go ahead and apply/backpatch this. It's certainly
> possible that more bugs remain to be found, but I have no good ideas
> about how to search for them, and in any case that wouldn't invalidate
> the patch as it stands.
And done. If anyone can think of additional
I wrote:
> Here's a draft patch against HEAD for this.
> I looked for problem spots by (a) testing with the STRESS_SORT_INT_MIN
> option I added in nbtcompare.c, (b) grepping for "x = -x" type code,
> and (c) grepping for "return -x" type code. (b) and (c) found several
> places that (a) didn't, w
Thomas Munro writes:
> I suppose someone might mistake this for a function that converts -42
> to 42... would something like INVERT_COMPARE_RESULT() be better?
I have no particular allegiance to the macro name; it's just the
first idea that came to mind.
regards, tom lane
On Fri, Oct 5, 2018 at 3:12 PM Tom Lane wrote:
> Here's a draft patch against HEAD for this.
+ * Invert the sign of a qsort-style comparison result, ie, exchange negative
+ * and positive integer values, being careful not to get the wrong answer
+ * for INT_MIN. The argument should be an integra
I wrote:
> Andres Freund writes:
>> On 2018-10-01 12:13:57 -0400, Tom Lane wrote:
>>> (2) Drop the restriction. This'd require at least changing the
>>> DESC correction, and maybe other things. I'm not sure what the
>>> odds would be of finding everyplace we need to check.
>> (2) seems more mai
On Tue, Oct 2, 2018 at 10:55 AM Andrew Dunstan
wrote:
> On 10/01/2018 12:50 PM, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2018-10-01 12:13:57 -0400, Tom Lane wrote:
> >>> Yeah. So our choices are
> >>>
> >>> (1) Retain the current restriction on what sort comparators can
> >>> produce.
On 10/01/2018 12:50 PM, Tom Lane wrote:
Andres Freund writes:
On 2018-10-01 12:13:57 -0400, Tom Lane wrote:
Yeah. So our choices are
(1) Retain the current restriction on what sort comparators can
produce. Find all the places where memcmp's result is returned
directly, and fix them. (I
On Mon, Oct 01, 2018 at 05:11:02PM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 10/01/2018 11:58 AM, Tom Lane wrote:
> >> Oooh ... apparently, on that platform, memcmp() is willing to produce
> >> INT_MIN in some cases. That's not a safe value for a sort comparator
> >> to produce --- w
Andrew Dunstan writes:
> On 10/01/2018 11:58 AM, Tom Lane wrote:
>> Oooh ... apparently, on that platform, memcmp() is willing to produce
>> INT_MIN in some cases. That's not a safe value for a sort comparator
>> to produce --- we explicitly say that somewhere, IIRC. I think we
>> implement DESC
On 10/01/2018 11:58 AM, Tom Lane wrote:
Mark Wong writes:
a | a |
uuid_cmp
--+--+-
---- | -1
Andres Freund writes:
> On 2018-10-01 12:13:57 -0400, Tom Lane wrote:
>> Yeah. So our choices are
>>
>> (1) Retain the current restriction on what sort comparators can
>> produce. Find all the places where memcmp's result is returned
>> directly, and fix them. (I wonder if strcmp has same issu
On 2018-10-01 12:13:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-10-01 11:58:51 -0400, Tom Lane wrote:
> >> Oooh ... apparently, on that platform, memcmp() is willing to produce
> >> INT_MIN in some cases. That's not a safe value for a sort comparator
> >> to produce --- we expli
Andres Freund writes:
> On 2018-10-01 11:58:51 -0400, Tom Lane wrote:
>> Oooh ... apparently, on that platform, memcmp() is willing to produce
>> INT_MIN in some cases. That's not a safe value for a sort comparator
>> to produce --- we explicitly say that somewhere, IIRC.
> Hm, that'd be pretty
On 2018-10-01 11:58:51 -0400, Tom Lane wrote:
> Mark Wong writes:
> > a | a
> > | uuid_cmp
> > --+--+-
> > ----1
Mark Wong writes:
> a | a
> | uuid_cmp
> --+--+-
> ---- | ----
> |
On Sun, Sep 30, 2018 at 12:38:46AM +0100, Andrew Gierth wrote:
> > "Andrew" == Andrew Dunstan writes:
>
> >> What is the size of a C "int" on this platform?
>
> Andrew> 4.
>
> Hmm.
>
> Because int being more than 32 bits is the simplest explanation for this
> difference.
>
> How about t
> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> Because int being more than 32 bits is the simplest explanation for
>> this difference.
Tom> Curious to hear your reasoning behind that statement? I hadn't
Tom> gotten further than "memcmp is broken" ... and neither of those
Tom>
Andrew Gierth writes:
> Because int being more than 32 bits is the simplest explanation for this
> difference.
Curious to hear your reasoning behind that statement? I hadn't gotten
further than "memcmp is broken" ... and neither of those theories is
tenable, because if they were true then a lot
> "Andrew" == Andrew Dunstan writes:
>> What is the size of a C "int" on this platform?
Andrew> 4.
Hmm.
Because int being more than 32 bits is the simplest explanation for this
difference.
How about the output of this query:
with d(a) as (values ('----':
On 09/29/2018 01:36 AM, Andrew Gierth wrote:
Mark> What should I try next?
What is the size of a C "int" on this platform?
4.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> "Mark" == Mark Wong writes:
Mark> What should I try next?
What is the size of a C "int" on this platform?
--
Andrew (irc:RhodiumToad)
Hi Andres,
On Fri, Sep 28, 2018 at 03:41:27PM -0700, Andres Freund wrote:
> On 2018-09-28 15:22:23 -0700, Mark Wong wrote:
> > On Fri, Sep 28, 2018 at 11:52:15AM -0700, Andres Freund wrote:
> > > Mark, is there anything odd for specific branches?
> >
> > No... I don't have anything in the config
Hi,
On 2018-09-28 15:22:23 -0700, Mark Wong wrote:
> On Fri, Sep 28, 2018 at 11:52:15AM -0700, Andres Freund wrote:
> > Mark, is there anything odd for specific branches?
>
> No... I don't have anything in the config that would be applied to
> specific branches...
Could you perhaps do some manua
On Fri, Sep 28, 2018 at 11:52:15AM -0700, Andres Freund wrote:
> Mark, is there anything odd for specific branches?
No... I don't have anything in the config that would be applied to
specific branches...
Regards,
Mark
--
Mark Wonghttp://www.2ndQuadrant.com/
Postg
Andres Freund writes:
> It seems Mark started a new buildfarm animal on s390x. It shows a pretty
> odd failure on 9.3 and 9.4, but *not* on newer animals:
No, lumpsucker is showing the same failure on 9.5 as well. I suspect
that the reason 9.6 and up are OK is that 9.6 is where we introduced
the
Hi,
It seems Mark started a new buildfarm animal on s390x. It shows a pretty
odd failure on 9.3 and 9.4, but *not* on newer animals:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lumpsucker&dt=2018-09-26%2020%3A30%3A58
== pgsql.build/src/test/regress/regression.diffs
=
26 matches
Mail list logo
