On Sat, Aug 5, 2017 at 4:03 PM, Andres Freund <andres@anarazel.de> wrote:
> Not saying it's not the fault of b8d7f053 et al, but I don't quite see
> how - whether something is a varlena tuple or not isn't really something
> expression evaluation has an influence over if it doesn't happen from
> within its code. That's the responsibility of the calling code, not from
> within the datum. So I don't quite understand how you got to b8d7f053?
It was a guess based on nothing more than what codepaths changed since
the last release.
While I think it's fair to assume for the time being that this is an
ICU bug, based on the fact that Valgrind won't complain when other
collations are used with the same data, I have a really hard time
figuring out why the datum tuplesort thinks that text is a
pass-by-reference type without a varlena header. That doesn't smell
like a bug in the ICU feature to me. Could an ICU bug really have
somehow made unrelated syscache lookups give wrong answers about
built-in types?
I'll try to find time to reproduce the problem next week. It should be
possible to work backwards from the weird issue within datumCopy(),
and figure out what the problem is.
--
Peter Geoghegan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs