Re: pg_upgrade --jobs - Mailing list pgsql-general

From Sherrylyn Branchaw
Subject Re: pg_upgrade --jobs
Date
Msg-id CAB_myF6HzMT8j9jfvFasj0G0w1PUfoV3ev5KsB1smum3faUxxg@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade --jobs  (senor <frio_cervesa@hotmail.com>)
Responses Re: pg_upgrade --jobs  (senor <frio_cervesa@hotmail.com>)
List pgsql-general
are there any shortcuts to upgrading that would circumvent exporting the entire schema?

By "shortcuts," do you mean you want to minimize the time and energy you put into the upgrade, or that you want to minimize database downtime? If you mean downtime, I was able to upgrade a customer-facing database with ~350,000 tables from Postgres 9.0 to 9.6 last year with only 86 seconds of downtime, using Slony, but I had to make many custom modifications to Slony and test thoroughly beforehand, and it was not for the faint of heart, the pressed for time, or the inexperienced. There may be better ways (and if so, I would be curious to learn about them), but Slony was the tool with which I was most familiar at the time.

This method does, of course, require exporting the entire schema, but because our only constraint was to minimize customer downtime, and the database was online while the schema was being exported, we didn't care how long it took. Your constraints may be different.

For those reading: we do know that 350,000 tables is Doing It Wrong, and we're getting rid of them, but we decided being on an EOLed version of Postgres was worse and should be fixed first.

Sherrylyn

pgsql-general by date:

Previous
From: Pavan Teja
Date:
Subject: Re: Logical replication failed recovery
Next
From: Adrian Klaver
Date:
Subject: Re: Logical replication failed recovery