On Thu, Nov 28, 2019 at 5:50 AM Michael Paquier <mich...@paquier.xyz> wrote: > > On Wed, Nov 27, 2019 at 04:09:57PM -0500, Robert Haas wrote: > > Yeah, I like #3 too. If we're going to the trouble to build all of > > this mechanism, it seems worth it to build the additional machinery to > > be precise about the difference between "looks like a problem" and "we > > don't know". > > Indeed, #3 sounds like a sensible way of doing things. The two others > may cause random problems which are harder to actually detect and act > on as we should avoid as much as possible a forced system-wide REINDEX > after an upgrade to a post-13 PG.
Thanks everyone for the feedback! Since there seems to be an agreement on #3, here's a proposal. What we could do is storing an empty string if the compatibility is unknown, and detect it in index_check_collation_version() to report a slightly different message. I'm assuming that not knowing the compatibility would be system-wide rather than per collation, so we could use an sql query like this: ALTER INDEX idx_name DEPENDS ON COLLATION UNKNOWN VERSION If adding (un)reserved keywords is not an issue, we could also instead use something along ALTER INDEX idx_name DEPENDS ON ALL COLLATIONS and/or ALL VERSIONS UNKNOWN, or switch to: ALTER INDEX idx_name ALTER [ COLLATION coll_name | ALL COLLATIONS ] DEPENDS ON [ UNKOWN VERSION | VERSION 'version_string' ] Obviously, specific versions would require a specific collation, and at least UNKNOWN VERSION would only be allowed in binary upgrade mode, and not documented. I have also some other ideas for additional DDL to let users deal with catalog update after a compatible collation library upgrade, but let's deal with that later. Then for pg_upgrade, we can add a --collations-are-binary-compatible switch or similar: If upgrading from pre-v13 - without the switch, we'd generate the VERSION UNKNOWN for all indexes during pg_dump in upgrade_mode - with the switch, do nothing as all indexes would already be pointing to the currently installed version If upgrading from post v13, the switch shouldn't be useful as versions will be restored, and if there was a collation library upgrade it should be handled manually, same as if such an upgrade is done without pg_upgrade-ing the cluster. I'd personally disallow it to avoid users to shoot themselves in the foot. Does this sounds sensible?
