Re: pg_upgrade --jobs

From: senor <frio_cervesa(at)hotmail(dot)com>
To: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_upgrade --jobs
Date: 2019-04-07 19:18:32
Message-ID: BYAPR01MB370123FD07BC67330F4952EAF7530@BYAPR01MB3701.prod.exchangelabs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I just noticed I missed Sherrylyn's post.
I did some reading about Slony and believe it is would be useful if I had the time to dig in. As pointed out, it's not an out-of-the box solution. It is included on the TODO list though. For now I can only dream of the 86 second down time.

Thanks

________________________________________
From: Sherrylyn Branchaw <sbranchaw(at)gmail(dot)com>
Sent: Sunday, April 7, 2019 6:43 AM
To: senor
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: pg_upgrade --jobs

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Andres Freund 2019-04-07 19:21:33 Re: assembling PGresults from multiple simultaneous queries (libpq, singlerowmode)
Previous Message Jess Wren 2019-04-07 19:17:19 Re: How to use full-text search URL parser to filter query results by domain name?