On Sun, Jun 28, 2015 at 8:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.)
I did attempt that before abbreviated keys went in, too. I didn't have
much luck finding the relevant information.
*My* point here is that this seems like taking unbounded
responsibility for a massive number of standard library bugs --
indisputable, garden-variety bugs. This bug was really likely to
result in a segfault back when Postgres lacked (but also arguably
needed) defenses against it, which was a period of about a year. The
reason that defenses were added was because there were several
complaints, but maybe those complaints were misdirected.
It might have been the right decision at the time to paper over the
problem, but only for a year or two. I'd only favor adding defenses if
it could be expected to take longer for the Solaris stdlib people to
ship a fix for their egregious bug than it would take for the next
Postgres point release. Why should that be true, though?
This just happened to be one of the more embarrassing, obvious stdlib
bugs that appeared in the last 15 years, and so we're talking about it
now, but there are plenty more, a good deal of which are far more
recent than this one. Where does it end? I don't see why this bug is
special just because 4 or 5 people complained about it on
pgsql-hackers over a decade ago.
--
Peter Geoghegan
