> It may take a while for slony replication to be in sync, but when it is,
there will be very little down time to switch over.
I agree in principle, which is why I chose Slony over pg_upgrade for my
company's very similar situation, but my experience was that, out of the
box, Slony was projected t
> The original scheduled downtime for one installation was 24 hours. By 21
hours it had not >completed the pg_dump schema-only so it was returned to
operation.
To me, your best option is to create a slony cluster with the version you
need to upgrade to.
When slony is in sync, simply make it the m
On 4/7/19 12:05 PM, senor wrote:
Thank you Adrian. I'm not sure if I can provide as much as you'd need for a
definite answer but I'll give you what I have.
The original scheduled downtime for one installation was 24 hours. By 21 hours
it had not completed the pg_dump schema-only so it was retu
e.
Thanks
From: Sherrylyn Branchaw
Sent: Sunday, April 7, 2019 6:43 AM
To: senor
Cc: pgsql-general@lists.postgresql.org
Subject: Re: pg_upgrade --jobs
are there any shortcuts to upgrading that would circumvent exporting the entire
schema?
By "shortcut
From: Adrian Klaver
Sent: Sunday, April 7, 2019 8:19 AM
To: senor; pgsql-general@lists.postgresql.org
Subject: Re: pg_upgrade --jobs
On 4/6/19 5:47 PM, senor wrote:
> Thanks Tom for the explanation. I assumed it was my ignorance of how the
> schema was handled that was making this look like a p
sts.postgresql.org
Subject: Re: pg_upgrade --jobs
On 4/6/19 6:50 PM, Tom Lane wrote:
senor <mailto:frio_cerv...@hotmail.com> writes:
[snip]
The --link option to pg_upgrade would be so much more useful if it
weren't still bound to serially dumping the schemas of half a million
tables.
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 datab
t DB design would be better but that's not
what I'm working with.
Thanks
From: Ron
Sent: Saturday, April 6, 2019 4:57 PM
To: pgsql-general@lists.postgresql.org
Subject: Re: pg_upgrade --jobs
On 4/6/19 6:50 PM, Tom Lane wrote:
senor <mailto
On 4/6/19 6:50 PM, Tom Lane wrote:
senor writes:
[snip]
The --link option to pg_upgrade would be so much more useful if it
weren't still bound to serially dumping the schemas of half a million
tables.
To be perfectly blunt, if you've got a database with half a million
tables, You're Doing It
senor writes:
> Is the limitation simply the state of development to date or is there
> something about dumping the schemas that conflicts with paralleling?
At minimum, it'd take a complete redesign of pg_dump's output format,
and I'm not even very sure what such a redesign would look like. All
gsql-general@lists.postgresql.org
Subject: Re: pg_upgrade --jobs
senor writes:
> Since pg_upgrade is in control of how it is calling pg_dump, is there a
> reason pg_upgrade cannot use the directory output format when calling
> pg_dump? Is the schema-only operation incompatible?
Well, ther
senor writes:
> Since pg_upgrade is in control of how it is calling pg_dump, is there a
> reason pg_upgrade cannot use the directory output format when calling
> pg_dump? Is the schema-only operation incompatible?
Well, there's no point in it. pg_dump can only parallelize data dumping,
and the
?
From: Adrian Klaver
Sent: Saturday, April 6, 2019 1:52 PM
To: senor; pgsql-general@lists.postgresql.org
Subject: Re: pg_upgrade --jobs
On 4/6/19 11:44 AM, senor wrote:
> The pg_upgrade --jobs option is not passed as an argument when it calls
> pg_d
On 4/6/19 11:44 AM, senor wrote:
The pg_upgrade --jobs option is not passed as an argument when it calls
pg_dump. I haven't found anything in docs or forums mentioning a reason for not
supporting under certain circumstances other than possibly for pre-9.2. The
pg_upgrade docs page states
The pg_upgrade --jobs option is not passed as an argument when it calls
pg_dump. I haven't found anything in docs or forums mentioning a reason for not
supporting under certain circumstances other than possibly for pre-9.2. The
pg_upgrade docs page states that it allows multiple CPUs to be
15 matches
Mail list logo
