Greetings, * Christoph Berg (m...@debian.org) wrote: > Re: Peter Eisentraut 2018-09-13 > <4f60612c-a7b5-092d-1532-21ff7a106...@2ndquadrant.com> > > Moreover, the fix for a collation version mismatch is, in the simplest > > case, to go around and REINDEX everything. Making the collation or > > collation version global doesn't fix that. It would actually make it > > harder because you couldn't run ALTER COLLATION REFRESH VERSION until > > after you have rebuilt all affected objects *in all databases*. > > Btw, I think a "reindexdb --all --collation" (and the SQL per-database > equivalent) that only rebuilds indexes that are affected by collations > would be immensely useful to have.
As I was discussing w/ Peter G during PostgresOpen, we'd have to wait until that reindexdb is complete before actually using anything in the system and that's pretty painful. While it sounds like it'd be a good bit of work, it seems like we really need to have a way to support multiple collation versions concurrently and to do that we'll need to have the library underneath actually providing that to us. Once we have that, we can build new indexes concurrently and swap to them (or, ideally, just issue REINDEX CONCURRENTLY once we support that..). Until then, it seems like we really need to have a way to realize that a given upgrade is going to require a big reindex, before actually doing the reindex and suddenly discovering that we can't use a bunch of indexes because they're out of date and extending the downtime for the upgrade to be however long it takes to rebuild those indexes... Thanks! Stephen
signature.asc
Description: PGP signature
