Jens Wilke writes:
> On Friday 06 May 2011 18:08:58 Tom Lane wrote:
>> There doesn't appear to be any fix for this that doesn't require a time
>> machine and/or a lot more effort than it's worth.
> Isn't it possible to backport the fix for pg_get_indexdef() to 8.* ?
We could install a kluge (no
On Friday 06 May 2011 18:08:58 Tom Lane wrote:
> There doesn't appear to be any fix for this that doesn't require a time
> machine and/or a lot more effort than it's worth.
Isn't it possible to backport the fix for pg_get_indexdef() to 8.* ?
> Suggest you rename
> the index in the 8.4 database
I wrote:
> It's not pg_upgrade's fault; it's pg_dump that's failing to reproduce
> the state of the source database.
> I'm inclined to think that maybe we should hack pg_dump to forcibly
> quote "concurrently" in this context, even though it doesn't do so
> anywhere else since the word isn't reser
Jens Wilke writes:
> Thanks Tom, yes, the index is named
> Indexes:
> "concurrently" btree (ulq_guid)
> In the 8.4 cluster and 9.0.4's pg_dumpall dumps it as
> CREATE INDEX concurrently ON foo USING btree (ulq_guid);
> That's it.
Oh, fun. We knew that not reserving that keyword was going t
On Friday 06 May 2011 17:18:29 Tom Lane wrote:
Hi Tom,
> Possibly if
> you showed us the actual (not obfuscated) table declaration, associated
> constraint declarations, and resulting index definition, things would be
> clearer.
Thanks Tom, yes, the index is named
Indexes:
"concurrently" btr
Jens Wilke writes:
> On Wednesday 04 May 2011 17:32:50 Tom Lane wrote:
>> Hmm, is this an autogenerated index?
> I don't think so.
> And to confirm, that i really deleted the new cluster between the pg_upgrade
> run and the dump|restore i did it again and was able to revive this index
> again:
On Wednesday 04 May 2011 17:32:50 Tom Lane wrote:
> Hmm, is this an autogenerated index?
I don't think so.
And to confirm, that i really deleted the new cluster between the pg_upgrade
run and the dump|restore i did it again and was able to revive this index
again:
foo=# \d+ foo.bar_idx
2011/5/6 Jens Wilke :
> On Thursday 05 May 2011 16:46:05 Cédric Villemain wrote:
>
>> I understood that you droped an index and when you dump/restore you
>> get your index again.
>
> Yes, that's it, after the pg_upgrade error, i removed the target data
> directory, and initialzed a new target DB.
>
On Thursday 05 May 2011 16:46:05 Cédric Villemain wrote:
> I understood that you droped an index and when you dump/restore you
> get your index again.
Yes, that's it, after the pg_upgrade error, i removed the target data
directory, and initialzed a new target DB.
After pg_dumpall|pg_dump i got a
2011/5/4 Jens Wilke :
>
> This index was deleted several weeks ago.
>
[...]
>
> after pg_dumpall|psql from 8.4 to 9.0 the undead index revived on the target
> DB:
I understood that you droped an index and when you dump/restore you
get your index again.
Did I miss something ?
--
Cédric Villemain
Jens Wilke writes:
> pg_upgrade brakes with the following error:
> Could not find foo.bar_idx in old cluster
Hmm, is this an autogenerated index? I suspect pg_upgrade can't cope if
it's been assigned a different name in the new cluster.
regards, tom lane
--
Sent via pg
Hi,
pg_upgrade brakes with the following error:
pg_upgrade 8.4.5 to 9.0.4:
Restoring user relation files
/data1/postgres/pgsql/foo/data_8.4/base/11564/2613 ^M
/data1/postgres/pgsql/foo/data_8.4/base/11564/2683
Could not find foo.bar_idx in old cluster
This index was dele
12 matches
Mail list logo
