Live data from Hacker News

The dangers of streaming across versions of glibc: A cautionary tale (2014)

postgresql.org

81–82 of 82 posts

Re: The dangers of streaming across versions of glibc: A cautionary tale (2014)

#81
post #65
post #48

Earlier quoted context omitted.

It's not that simple. SQL in particular actually requires lexicographical sorting, so you need to do it somehow. The problem is relying on lexicographical sorting remaining fixed when it isn't. Per the unicode standard, lexicographical sorting rules are subject to change. So now you need a mechanism to detect/manage those changes.

That's done via unicode/uchar.h: #define U_UNICODE_VERSION "9.0" in icu. pcre2 has PCRE2_CONFIG_UNICODE_VERSION 10 fribidi has FRIBIDI_UNICODE_VERSION "6.2.0" libc's need something similar. In safelibc I do have nothing so far, but I'm at 11.0

Right... so properly detecting when U_UNICODE_VERSION in the replication target differs from U_UNICODE_VERSION in the source, and adjusting for it is what's needed. PostgreSQL wasn't doing this in 2014.

Re: The dangers of streaming across versions of glibc: A cautionary tale (2014)

#82
post #81
post #65

Earlier quoted context omitted.

That's done via unicode/uchar.h: #define U_UNICODE_VERSION "9.0" in icu. pcre2 has PCRE2_CONFIG_UNICODE_VERSION 10 fribidi has FRIBIDI_UNICODE_VERSION "6.2.0" libc's need something similar. In safelibc I do have nothing so far, but I'm at 11.0

Right... so properly detecting when U_UNICODE_VERSION in the replication target differs from U_UNICODE_VERSION in the source, and adjusting for it is what's needed. PostgreSQL wasn't doing this in 2014.

Exactly. I'm just not happy with the types of these defines. Only major updates need to be tracked, so the PCRE format seems to be the best. But all others are using strings, not an integer.
Post reply on HN