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