Restore error -- database escape problem?

AI-generated summary

The user is experiencing issues restoring a Discourse database to a hosted site, despite successful restoration on their Droplet. The error logs indicate unrecognized configuration parameter “row_security” and syntax errors. sam suggests the issue might be due to restoring incompatible versions of PostgreSQL (pg). codinghorror advises checking Postgres versions on both sides to ensure they match. The hosting company has switched to the same Postgres version as the user, but the issue persists. Falco believes the problem is caused by the row security feature introduced in the last version, making the dumps incompatible.

I’m having trouble restoring to a hosted site. It restored fine on my Droplet, but not at the place that’s hosting Discourse for a client. I suppose it’s their problem to figure out, but I’m curious about what it could be.

. . .

. . .
A bunch of these:

and stuff like this:

It looks like somehow the database is configured such that stuff isn’t getting escaped properly?

Any ideas here @tgxworld?

I have seen this before … I think its related to trying to restore incompatible versions of pg.

Oh. Golly. That sounds painful to resolve. But that sounds like a likely explanation. Thanks.

So check Postgres versions on both sides and make sure they match.

The hosting company switched to the same Postgres I had used.

It’s troublesome that PG is so finicky about restoring across versions. I guess it happens rarely enough that it’s not worth trying to catch it.

I think it’s the row security from last version that made the dumps not compatible.