As long as your container’s config is using the default postgres.template.yml, the upgrade of the PostgreSQL data directory would happen automatically the next time you do a ./launcher rebuild. In the event that the PostgreSQL data directory fails to upgrade, please follow the instructions printed by ./launcher rebuild or you may refer to the instructions in this template. If following the instructions does not work for you, please post the full log of ./launcher rebuild here so that we can help you restore your instance into a working state.
I, [2018-04-14T18:05:10.944387 #15] INFO -- : Upgrading PostgreSQL from version 9.5 to 10
WARNING: Upgrading PostgresSQL would require an addtional 19M of disk space
Please free up some space, or expand your disk, before continuing.
Earlier I got an error saying ‘requiring addtional(sic) 21M of disk space’, I made 2GB of additional space, and now it still wants 19 MB.
How much disk space does this process need? In addition, I can’t easily expand disk space on this physical server whatsoever, nor free up much more either (uploads/data use practically all disk space).
We noticed that ./launcher rebuild with postgres 10 fail when the variable LANG is setted to fr_FR.UTF8 in app.yml. postgres just won’t boot up.
It wasn’t the case with postgres 9.5, but maybe we shouldn’t have changed the locale (in this case, it might not be useful to put in the sample app.yml this env variable)
I thought that you were using -h at some point, because
But maybe you fixed the error described above:(that suggested there was a problem detecting disk space correctly) already and I missed it. Sorry if my post was confusing and not helpful.
Hmm that is a good point actually. @sam Do you know if Discourse search would be affected if the LANG is configured differently? Otherwise, I think we should just bake the ENV into postgres.template.yml.
Yeah you basically want fulltext search to be configured with the right defaults otherwise the tokenizer does not work right and search results suffer. Changing this after the fact is real hard.
but do note that the upgrade will fail if you change the locale when trying to upgrade. You’ll then need to upgrade postgres via pg_dump, there will be instructions printed when the upgrade fails.
Everything went well when rebuilding with fr_FR locale, thank for the fix
So I assume that the search will be less good for the few days we used the wrong local ? Is that the only downside ? Good to have this information about the LANG variable.
I think we need to test this cause we changed stuff over the years and it may no longer be a big issue. The bottom line is that we want pg using french stop words and french snowball when tokenizing for search, now I think we have a bunch of internal changed that help force things but we may have missed some spots. Setting to fr_FR is safest but it may not be needed.
I found what might have been the problem above. I did an upgrade of a huge database on a small disk yesterday and that free_disk check fails if /shared isn’t the same partition as /.