Maybe this is useful for other admins. If you're:
ansible-galaxy installevery time (or don't want the bandwidth/time waste of it)
Here's a python script to clean out the dependencies in your roles folder which don't match the the versions you've requested in your requirements.yml file.
ansible-galaxy install -p roles -r requirements.yml will not re-download or replace packages at the wrong version unfortunately. They do provide a flag to force this... but it re-installs every role. Hence this python script to selectively remove the roles that are now outdated.
psql:backup/test.full.2021-11-02.sql:1732648574: ERROR: index row size 2712 exceeds btree version 4 maximum 2704 for index "ix_history_annotation_association_annotation"
Stefan has looked at it and commented this:
Ok, I think I'm beginning to understand what's going on...
Btree-indexing has been re-done in v12 already; from v12 on, btree indexes are "version 4" with additional capabilities. So far so good.
Now, according to what I gather from earlier occurrences of the error message in question found on the web, the max size of a value that could be hashed using btrees used to be 2713 (bytes, I presume). But according to the error message I got when loading the test backup (see above) with v4 that limit has been decreased to 2704.
But our current database layout still assumes that a size of 2712 is ok - aye, there's the rub!
The interesting question is of course: how does the ORG manage to run PG v12 just fine with the same DB schema?
I suspect that they did not upgrade to v12 by backing up, installing the new version and finally re-loading the backup but rather did an in-place upgrade using pg_upgrade(1). This process just keeps the old indexes around, at v3. And unless they perform a REINDEX operation they can still use that old index happily everafter...
Unfortunately, I see no way to create v3 btree indexes in PG v12 and up, no suitable parameter for CREATE INDEX as far as I can see.
galaxy_main=> SELECT idx_scan,idx_tup_read,idx_tup_fetch FROM pg_stat_user_indexes WHERE indexrelname='ix_history_annotation_association_annotation'; idx_scan | idx_tup_read | idx_tup_fetch ----------+--------------+--------------- 0 | 0 | 0 (1 row)