Hello again,
well, still everything is working.
What information do you need to get into this issue?
Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some
more or less changed enum_add and enum_del (Which are appended at the
end) to be able to change enums within
On 2012-12-19 16:51:32 +0100, Bernhard Schrader wrote:
Hello again,
well, still everything is working.
What information do you need to get into this issue?
Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some more
or less changed enum_add and enum_del (Which are appended
On 12/19/2012 10:56 AM, Andres Freund wrote:
On 2012-12-19 16:51:32 +0100, Bernhard Schrader wrote:
Hello again,
well, still everything is working.
What information do you need to get into this issue?
Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some more
or less changed
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-19 16:51:32 +0100, Bernhard Schrader wrote:
Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some more
or less changed enum_add and enum_del (Which are appended at the end) to be
able to change enums within transactions.
On 12/19/2012 11:31 AM, Tom Lane wrote:
enum_add is all right as long as you are careful to commit its
transaction before inserting the new value anywhere.
It's not really all right for post-9.0 versions. For example, this is wrong:
--postgres 9.2 or higher
Andrew Dunstan and...@dunslane.net writes:
what is even worse is that this procedure doesn't take any care at all
of the ordering rule for even numbered enum oids.
Good point. You really should use ALTER TYPE ADD VALUE, on versions
where that's available.
regards, tom
On 12/18/2012 02:41 AM, Bruce Momjian wrote:
On Mon, Dec 17, 2012 at 12:14:29PM +0100, Bernhard Schrader wrote:
Hello together,
last thursday I upgraded one of our 9.0.6 postgresql servers to
9.2.2 with pg_upgrade. So far everything seemed to work but we now
discover problems with the enum
On 12/18/2012 02:41 AM, Bruce Momjian wrote:
On Mon, Dec 17, 2012 at 12:14:29PM +0100, Bernhard Schrader wrote:
Hello together,
last thursday I upgraded one of our 9.0.6 postgresql servers to
9.2.2 with pg_upgrade. So far everything seemed to work but we now
On 12/18/2012 03:45 AM, Bernhard Schrader wrote:
On 12/18/2012 02:41 AM, Bruce Momjian wrote:
On Mon, Dec 17, 2012 at 12:14:29PM +0100, Bernhard Schrader wrote:
Hello together,
last thursday I upgraded one of our 9.0.6 postgresql servers to
9.2.2 with pg_upgrade. So far everything seemed to
On Tue, Dec 18, 2012 at 10:52:46AM -0500, Andrew Dunstan wrote:
The translations from oid to label are in pg_enum, but it looks like
somehow you have lost that mapping. I'm not sure what you've done
but AFAICT pg_upgrade is doing the right thing.
I just did this (from 9.0 to 9.2) and the
On 12/18/2012 05:22 PM, Bruce Momjian wrote:
On Tue, Dec 18, 2012 at 10:52:46AM -0500, Andrew Dunstan wrote:
The translations from oid to label are in pg_enum, but it looks like
somehow you have lost that mapping. I'm not sure what you've done
but AFAICT pg_upgrade is doing the right thing.
I
Bernhard Schrader bernhard.schra...@innogames.de writes:
Beside of that, we tested a little bit more with the failing query:
The statement which is causing the error is a big UPDATE-statement with
FROM. After some testing we figured out that the subselect in the
FROM-clause is working fine.
On 12/18/2012 01:24 PM, Tom Lane wrote:
Bernhard Schrader bernhard.schra...@innogames.de writes:
Beside of that, we tested a little bit more with the failing query:
The statement which is causing the error is a big UPDATE-statement with
FROM. After some testing we figured out that the
On 2012-12-18 13:24:12 -0500, Tom Lane wrote:
Bernhard Schrader bernhard.schra...@innogames.de writes:
Beside of that, we tested a little bit more with the failing query:
The statement which is causing the error is a big UPDATE-statement with
FROM. After some testing we figured out that the
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-18 13:24:12 -0500, Tom Lane wrote:
Does the table being updated have any indexes on enum columns? I'm
suspicious that the bogus OID is in an index page somewhere, and not
in the table at all.
I already wondered whether it could be a
On 12/18/2012 02:34 PM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-18 13:24:12 -0500, Tom Lane wrote:
Does the table being updated have any indexes on enum columns? I'm
suspicious that the bogus OID is in an index page somewhere, and not
in the table at all.
I
Andrew Dunstan and...@dunslane.net writes:
He's upgrading from 9.0, which didn't have enum extension at all, and
where odd enums didn't mean anything special.
Really? The noncontiguous pg_enum OIDs shown in
http://archives.postgresql.org/pgsql-hackers/2012-12/msg01089.php
suggest strongly
On 12/18/2012 02:58 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
He's upgrading from 9.0, which didn't have enum extension at all, and
where odd enums didn't mean anything special.
Really? The noncontiguous pg_enum OIDs shown in
Andrew Dunstan and...@dunslane.net writes:
People have been known to hack pg_enum on their own, especially before
we added enum extension.
Of course, if they do that they get to keep both pieces.
Yeah ... this would be very readily explainable if there had been a
manual deletion from pg_enum
On 12/18/2012 09:38 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
People have been known to hack pg_enum on their own, especially before
we added enum extension.
Of course, if they do that they get to keep both pieces.
Yeah ... this would be very readily explainable if there
On Mon, Dec 17, 2012 at 12:14:29PM +0100, Bernhard Schrader wrote:
Hello together,
last thursday I upgraded one of our 9.0.6 postgresql servers to
9.2.2 with pg_upgrade. So far everything seemed to work but we now
discover problems with the enum types. If we run one specific query
it breaks
On Mon, Dec 17, 2012 at 12:14:29PM +0100, Bernhard Schrader wrote:
Hello together,
last thursday I upgraded one of our 9.0.6 postgresql servers to
9.2.2 with pg_upgrade. So far everything seemed to work but we now
discover problems with the enum types. If we run one specific query
it breaks
22 matches
Mail list logo
