Discourse on postgres 12 breaks upgrades

installation
1

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:

  - "templates/postgres.12.template.yml"

Running ./launcher rebuild app:

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.

2

its looking for postgress 13 and not 12.

{“filename”=>“/etc/postgresql/13/main/pg_hba.conf”,

3

Indeed. That is the problem.

4

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?

2 Likes
5

That would work, yes. Desperately trying not to have to do that.

1 Like
6

Might seem scary, but you’d have enough safeguards there, you can always bring the old server back online.

1 Like
7

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.

8

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?

2 Likes
9

No, I run a very large forum.

2 Likes
10

Ah! A nice problem to have! :slight_smile:

11

I suppose, it’s not like I’m paid! :wink:

1 Like
12

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.

5 Likes
13

Fixed in

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.

5 Likes
14

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.

15

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.

1 Like
16

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!

2 Likes
17

Yes, I copy-pasted without thinking - sorry and thanks for fixing it!

1 Like
19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.