On 03/25/2014 05:23 PM, Sam Saffron wrote:
Sorry, its part of a rather elaborate docker based upgrade, that
install is just done to get the binaries, the data is all in a
completely different location which is untouched.
So there are two instances of 9.2 in play at one time?
The upgrade process
On 03/25/2014 05:14 PM, Sam Saffron wrote:
9.2 is the problem instance, 9.3 is clean, I am able to do many
upgrades without issues with the same script (which spawns a clean 9.3
instance and then pg_upgrades to it.)
Alright that makes sense, though I am still unclear about the below from
your
9.2 is the problem instance, 9.3 is clean, I am able to do many
upgrades without issues with the same script (which spawns a clean 9.3
instance and then pg_upgrades to it.)
On Wed, Mar 26, 2014 at 11:13 AM, Adrian Klaver
wrote:
> On 03/25/2014 05:03 PM, Sam Saffron wrote:
>>
>> Yes Adrian,
>>
>>
On 03/25/2014 05:03 PM, Sam Saffron wrote:
Yes Adrian,
That is correct (upgraded 9.2 to 9.3 via pg_dump), more than happy to
provide pg devs with the actual db if needed.
Pretty sure the target db is good, especially since we just dumped a
single db (did not do a dump_all)
Well it has more to
Yes Adrian,
That is correct (upgraded 9.2 to 9.3 via pg_dump), more than happy to
provide pg devs with the actual db if needed.
Pretty sure the target db is good, especially since we just dumped a
single db (did not do a dump_all)
On Wed, Mar 26, 2014 at 10:58 AM, Adrian Klaver
wrote:
> On 03/
On 03/25/2014 04:32 PM, Sam Saffron wrote:
Thanks heaps Tom,
I can confirm corrupt db upgrades fine with pg_dump. Was wondering if
there are any plans to add a --no-validate to pg_upgrade, since the
crash seems only to happen during validation.
Hmm, so I am still unclear on this. The 'corrupt'
Sam Saffron writes:
> I can confirm corrupt db upgrades fine with pg_dump. Was wondering if
> there are any plans to add a --no-validate to pg_upgrade, since the
> crash seems only to happen during validation.
Skipping validation would probably just result in the same error happening
later, when
Thanks heaps Tom,
I can confirm corrupt db upgrades fine with pg_dump. Was wondering if
there are any plans to add a --no-validate to pg_upgrade, since the
crash seems only to happen during validation.
Cheers
Sam
On Wed, Mar 26, 2014 at 3:19 AM, Tom Lane wrote:
> Sam Saffron writes:
>> Why wou
Sam Saffron writes:
> Why would
> "ERROR: operator does not exist: name !~ unknown"
> Come up ?
It's hard to explain that as anything except corrupted system catalogs
in your existing database :-(. If you were really lucky, reindexing
pg_operator would fix it; but since pg_operator is usually p
On 03/24/2014 04:58 PM, Sam Saffron wrote:
I am getting the following failure on a customer DB upgrading 9.2 to 9.3
Selecting previously unselected package postgresql-9.2.
Unpacking postgresql-9.2 (from
.../postgresql-9.2_9.2.8-1.pgdg12.4+1_amd64.deb) ...
Processing triggers for postgresql-commo
I am getting the following failure on a customer DB upgrading 9.2 to 9.3
Selecting previously unselected package postgresql-9.2.
Unpacking postgresql-9.2 (from
.../postgresql-9.2_9.2.8-1.pgdg12.4+1_amd64.deb) ...
Processing triggers for postgresql-common ...
Setting up postgresql-client-9.2 (9.2.8
11 matches
Mail list logo
