| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bernhard Schrader <bernhard(dot)schrader(at)innogames(dot)de> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [ADMIN] Problems with enums after pg_upgrade |
| Date: | 2012-12-18 18:24:12 |
| Message-ID: | 11487.1355855052@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-hackers |
Bernhard Schrader <bernhard(dot)schrader(at)innogames(dot)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. And if we simplify the UPDATE-statement
> it's also working. We're able to show the data and we're able to do
> simple updates on the table. But the two things combined are not
> working.
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.
If that is the answer, then reindexing said index would get rid of
the problem (as well as all evidence that would help us find out how
it happened ...)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2012-12-18 18:37:15 | Re: [ADMIN] Problems with enums after pg_upgrade |
| Previous Message | Bernhard Schrader | 2012-12-18 18:06:37 | Re: [ADMIN] Problems with enums after pg_upgrade |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2012-12-18 18:37:15 | Re: [ADMIN] Problems with enums after pg_upgrade |
| Previous Message | Tom Lane | 2012-12-18 18:21:14 | Re: pg_basebackup from cascading standby after timeline switch |