Peter Geoghegan <pg@heroku.com> writes:
> 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, your arguments are beginning to sound like desperate excuse-making.
The reason that bug is "special" is that it looks like a crash in
Postgres, one that people have complained of because they didn't see it
in other programs, which is not totally surprising because it requires
a somewhat unusual usage of strxfrm(). I think the dumb two-call
implementation exhibited in convert_string_datum() is mainstream usage,
which would explain why Sun hadn't noticed the bug ages ago.
It might be all right to refuse to support platforms that have this
bug, but I think we need to determine with some more clarity just
how widespread the bug still is, and in any case we should at least
install some defense that would allow us to report that libc is
buggy. Otherwise we'll be back to fielding bug reports that trace
to this, which is no fun for anyone and does not make us look good.
regards, tom lane