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)
Alright...I can't find where environment variables are declared for Galaxy.
We're trying to migrate our Apollo services and I cannot make the environment variable change for the life of me. I thought it was in
/etc/supervisor/conf.d/<files> but...evidently it isn't picking up. Even after restart.
Is there another place that environment variables can get declared? Something perhaps that I am missing? At least obvious ones.
<we don't use ansible atm, we are currently old school/bare metal>