# Discourse on postgres 12 breaks upgrades
**URL:** https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814
**Category:** Self-hosting
**Created:** [August 26, 2021, 2:50pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814 "2021-08-26T14:50:02Z")
**Posts on this page:** 18
**Page:** 1
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [August 26, 2021, 2:50pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/1 "2021-08-26T14:50:02Z")
We’re running postgres v12 as the v13 upgrade requires too much disk space. It looks like compatibility with v12 may have been broken? Is this deliberate? If so it means we can never upgrade Discourse again.
Running `./launcher start app` got us back online so it isn’t a production issue right now, but being unable to upgrade even for security issues etc would be very bad news for us.
From app.yml:
```plaintext
- "templates/postgres.12.template.yml"
```
Running `./launcher rebuild app`:
```plaintext
FAILED
--------------------
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/13/main/pg_hba.conf
Location of failure: /pups/lib/pups/replace_command.rb:8:in `read'
replace failed with the params {"filename"=>"/etc/postgresql/13/main/pg_hba.conf", "from"=>"/^host.*all.*all.*::1\\/128.*$/", "to"=>"host all all ::/0 md5"}
0ba8112e6efa1ac2dd75af8a1da8eea0937e7aefbca2df28b22d27e9608d1479
**FAILED TO BOOTSTRAP** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
```
Currently running version 2.8.0.beta4 75b0d6df93.
---
### Author:  [@IAmGav](https://meta.discourse.org/u/IAmGav)
#### Post date: [August 26, 2021, 2:59pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/2 "2021-08-26T14:59:19Z")
its looking for postgress 13 and not 12.
> {“filename”=\>“/etc/postgresql/13/main/pg\_hba.conf”,
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [August 26, 2021, 3:00pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/3 "2021-08-26T15:00:30Z")
Indeed. That is the problem.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [August 26, 2021, 7:02pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/4 "2021-08-26T19:02:28Z")
> [@Wingtip](#):
>
> We’re running postgres v12 as the v13 upgrade requires too much disk space.
Why don’t you back-up, create a totally fresh discourse instance (which should default postgres 13), restore back-up and remap the server in DNS?
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [August 26, 2021, 7:03pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/5 "2021-08-26T19:03:51Z")
That would work, yes. Desperately trying not to have to do that.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [August 26, 2021, 7:05pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/6 "2021-08-26T19:05:49Z")
Might seem scary, but you’d have enough safeguards there, you can always bring the old server back online.
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [August 26, 2021, 7:31pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/7 "2021-08-26T19:31:54Z")
It’s less scary than annoying work I’d like to avoid, combined with telling my forum they’re going to lose a day or two of posts. Would like the Discourse guys to say “Of course we still work on PG12, that’s just a bug, we’ll get that fixed up” ideally.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [August 26, 2021, 7:36pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/8 "2021-08-26T19:36:06Z")
I can’t see why that’s necessary.
1. Prepare new server on subdomain?
2. Enter read-only mode on existing server, create back-up
3. Pull in back-up on new server
4. Remap DNS
5. Rebuild new server with primary discourse subdomain.
This process could take 30 mins?
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [August 26, 2021, 7:37pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/9 "2021-08-26T19:37:45Z")
No, I run a _very_ large forum.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [August 26, 2021, 7:38pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/10 "2021-08-26T19:38:11Z")
Ah! A nice problem to have! 🙂
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [August 26, 2021, 7:38pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/11 "2021-08-26T19:38:53Z")
I suppose, it’s not like I’m paid! 😉
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [August 26, 2021, 7:41pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/12 "2021-08-26T19:41:43Z")
Oh I see it’s a bug introduced by a community PR. As we don’t run PG12 anywhere it went under the radar. Give me a few minutes.
>
>
> In a Docker environment configured for IPv6 (\`"ipv6": true\` in \_/etc/docker/daem…on.json\_) a Discourse web container may not be able to connect to the data container using IPv6.
>
> This PR fixes it by replacing \`::1/128\` in \_/etc/postgresql/13/main/pg\_hba.conf\_ by \`::/0\`. That's a similar approach as already working for IPv4.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [August 26, 2021, 7:46pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/13 "2021-08-26T19:46:51Z")
Fixed in
[https://github.com/discourse/discourse\_docker/pull/566](https://github.com/discourse/discourse_docker/pull/566)
Can you please try rebuilding again @Wingtip ?
That said, we don’t run PG12 anymore, so we may introduce some SQL syntax exclusive to PG13+ anytime in core, so it would be a good idea to schedule the upgrade _someday_.
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [August 26, 2021, 7:48pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/14 "2021-08-26T19:48:26Z")
I’ll check it out right after I take another snapshot of my VM.
It’s seriously annoying how PG requires a ton of disk space to upgrade. Don’t have this problem on Oracle or MySQL, they just upgrade in-place.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [August 26, 2021, 7:53pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/15 "2021-08-26T19:53:09Z")
`pg_upgrade` provides a single `--link` flag to allow for in-place upgrades.
We opted to **not** use it in our “newbie-friendly” launcher upgrade script as 99% of installs are running in a cloud VM that can easily and cheaply extend the disk size.
But it’s there as an option for people who prefer to do the upgrade manually in order to save disk space during the process.
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [August 26, 2021, 7:54pm UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/16 "2021-08-26T19:54:18Z")
There were 2 solutions provided; as I recall one basically needed triple the size of the entire DB and the other needed like double. If it can be done in-place, documenting that would be very useful.
Edit: The fix worked, thank you!
---
### Author:  [@fuerst](https://meta.discourse.org/u/fuerst)
#### Post date: [August 27, 2021, 6:32am UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/17 "2021-08-27T06:32:37Z")
Yes, I copy-pasted without thinking - sorry and thanks for fixing it!
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [September 26, 2021, 6:33am UTC](https://meta.discourse.org/t/discourse-on-postgres-12-breaks-upgrades/201814/19 "2021-09-26T06:33:02Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.