On Sun, Jun 28, 2015 at 4:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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 hardly matters much, but I don't think that it is. I think the
issue is entirely explained by sloppy code in the Solaris 8 stdlib.
Anyone using strxfrm() is probably doing so for exactly the same
reason as bttext_abbrev_convert() -- making sorting text in a
collation-aware fashion faster. That's what strxfrm() is more or less
advertised for by the glibc docs, for example, and in fact the
strxfrm() glibc example involves resizing a buffer to fit [1], to
avoid doubling the number of strxfrm() calls.
For that reason, I think that convert_string_datum() is much further
from mainstream usage than bttext_abbrev_convert().
> 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.
I can definitely get behind having a defense at startup. That seems
like cheap insurance. It probably isn't too much work to adopt Noah's
test program.
[1] http://www.gnu.org/software/libc/manual/html_node/Collation-Functions.html
--
Peter Geoghegan
