Re: Solaris testers wanted for strxfrm() behavior - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Solaris testers wanted for strxfrm() behavior
Date
Msg-id 19392.1435505502@sss.pgh.pa.us
Whole thread Raw
In response to Re: Solaris testers wanted for strxfrm() behavior  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Solaris testers wanted for strxfrm() behavior  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes:
> On Sat, Jun 27, 2015 at 7:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think the point of Noah's query is to find out whether "ancient" is an
>> accurate description.

> You said it yourself at the time -- why trust the strxfrm()
> implementation when a NULL pointer is passed? It may have worked on
> someone's machine in 2003, but that isn't a very good reason. It was
> never a documented part of the interface that this fails or that
> works; how could it be? This Solaris strxfrm() issue is (in the
> simplest and least contentious sense) a bug. It is not a portability
> issue. Someone made a mistake, and most likely the mistake was
> corrected in the next point release.

The point here is to *find out*, rather than assuming.  I agree that
Sun should have been embarrassed that such a bug ever made it into
a released libc, but it did.  The question is how long did it take
them to notice and fix it.  Assuming that it happened in "the next point
release", with absolutely no evidence to support that optimistic guess,
doesn't seem like a good idea to me.

(BTW, another way to settle the question might be to check the Solaris
release history.  Wonder if that's available anywhere.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_file_settings view vs. Windows
Next
From: Tom Lane
Date:
Subject: Re: drop/truncate table sucks for large values of shared buffers