On Sun, Jun 28, 2015 at 8:31 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
