On Tue, Mar 22, 2016 at 4:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> BTW, the glibc discussion starting here:
> https://sourceware.org/ml/libc-alpha/2015-09/msg00196.html
> should put substantial fear in us about the advisability of putting strxfrm
> results on-disk, as I understand we're now doing in btrees.
>
> I was led to that while looking to see if there were any already-filed
> glibc bug reports concerning this issue. AFAICS there are not, which
> is odd if the bug is gone in more recent releases ...
I always knew it wouldn't fly to store strxfrm on disk, and we don't
do that. I actually quoted a paper saying just that at one point. I
specifically acknowledged that that was clearly a non-starter a couple
of times.
B-Trees are built based on strxfrm() comparisons at a point in time.
strxfrm() should be able to produce the same results as strcoll().
That is what it's documented to do, in C90. glibc has license to
change the strxfrm() representation while still producing answers
consistent with previous answers. Just not during an ongoing sort,
obviously.
It's not 100% clear that we have a contract with glibc to never change
collation rules, even for strcoll(), but our current use of strxfrm()
should not have made that any worse. Problems only cropped up because
of bugs in glibc.
--
Peter Geoghegan
