On Sat, Dec 3, 2016 at 2:52 PM, Maeldron T. <maeldron@xxxxxxxxx> wrote: > Upgrading FreeBSD from 10 to 11 might break your database. It probably won’t > be corrupted but it will be useless until you dump-import it, and you might > need to do manual fixing. Sorry to hear about your arm and your database. The collation support was changed in FreeBSD 11 (in collaboration with Illumos and DragonflyBSD[1]). From FreeBSD's UPDATING: Databases administrators will need to reindex their databases given collation results will be different. This is a problem that faces users of Postgres on all operating systems, too, for example recently some GNU/Linux users had indexes silently corrupted because of change to the glibc locale data for German. One approach is to use "amcheck"[2] (proposed for future inclusion in PostgreSQL) to check if indexes are still sane, any time the collation definition files or libc itself might have changed. > (Maybe database clusters should have a header that wouldn’t allow > incompatible server versions to process the existing data. I wonder if it > would take more than 8 bytes per server. But I guess it was not know to be > incompatible. Even my two CIs didn’t show it.) I had some thoughts along those lines too[3]. I thought about checksumming libc and all relevant collation files (ie OS specific files) so you could notice when anything that could bite you changes (that is just some sketched out ideas, not production code). Some have suggested that PostgreSQL should stop using OS collations and adopt ICU[4] and then use its versioning metadata. Of course some people already use ICU on FreeBSD because the old strcoll implementation didn't play well with Unicode, but those users are still presumably exposed to silent corruption when ICU changes because AFAIK that didn't keep track of ICU versions. [1] http://blog.etoilebsd.net/post/This_is_how_I_like_opensource [2] https://www.postgresql.org/message-id/flat/CAM3SWZQzLMhMwmBqjzK+pRKXrNUZ4w90wYMUWfkeV8mZ3Debvw@xxxxxxxxxxxxxx [3] https://github.com/macdice/check_pg_collations [4] https://www.postgresql.org/message-id/flat/85364fde-091f-bbc0-fec2-e3ede39840a6@xxxxxxxxxxxxxxx -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general