Thread: PostgreSQL on Solaris: Changing Compilers During Point Upgrade
I'm working on a system where postgres 8.2.1 was built from source on Solaris 10 using gcc. Based on a number of recommendations, we decided to rebuild postgres Sun Studio cc. Without changing platforms, I wouldn't've expected the compiler to make a difference, but we just built 8.2.2 from source using cc, and now we're seeing this type of error in the logs:
ERROR: attribute 3 has wrong type
DETAIL: Table has type character varying, but query expects character varying.
Is changing compilers under postgres on the same platform without a dump/reload a Bad Idea?
More important: Has this risked any catastrophic data corruption? If we just switch to a gcc 8.2.2, will we be fine?
--
Thomas F. O'Connell
optimizing modern web applications
: for search engines, for usability, and for performance :
On Tue, Feb 06, 2007 at 09:43:01AM -0600, Thomas F. O'Connell wrote:
> DETAIL: Table has type character varying, but query expects
> character varying.
In another thread, someone else is reporting this too. I'm
wondering whether something went wrong in the 8.2.2 release.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
Unfortunately reformatting the Internet is a little more painful
than reformatting your hard drive when it gets out of whack.
--Scott Morris
On Tue, Feb 06, 2007 at 09:43:01AM -0600, Thomas F. O'Connell wrote:> DETAIL: Table has type character varying, but query expects> character varying.In another thread, someone else is reporting this too. I'mwondering whether something went wrong in the 8.2.2 release.
Is this the other thread?
This looks like it's affecting 8.1...
--
Thomas F. O'Connell
optimizing modern web applications
: for search engines, for usability, and for performance :
On Feb 6, 2007, at 9:54 AM, Andrew Sullivan wrote: > On Tue, Feb 06, 2007 at 09:43:01AM -0600, Thomas F. O'Connell wrote: >> DETAIL: Table has type character varying, but query expects >> character varying. > > In another thread, someone else is reporting this too. I'm > wondering whether something went wrong in the 8.2.2 release. The error message originates in backend/executor/ nodeFunctionscan.c:tupledesc_match. In this case the error is being caused by having a functional index (lower(fieldname)) on a table. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
"Thomas F. O'Connell" <tf@o.ptimized.com> writes:
> but we just built 8.2.2 from source using cc, and now we're seeing
> this type of error in the logs:
> ERROR: attribute 3 has wrong type
> DETAIL: Table has type character varying, but query expects
> character varying.
This has nothing to do with your compiler :-(
regards, tom lane
On Feb 6, 10:33 am, t...@sss.pgh.pa.us (Tom Lane) wrote:
> "Thomas F. O'Connell" <t...@o.ptimized.com> writes:
>
> > but we just built 8.2.2 from source using cc, and now we're seeing
> > this type of error in the logs:
> > ERROR: attribute 3 has wrong type
> > DETAIL: Table has type character varying, but query expects
> > character varying.
>
> This has nothing to do with your compiler :-(
I just wanted to eliminate that variable. It took me a while to track down the source of the error in the source.
I saw this nearby thread on -hackers:
The tables in question generating these errors in this database do indeed have functional indexes. Is there a known fix, or does this qualify as a bug?
--
Thomas F. O'Connell
optimizing modern web applications
: for search engines, for usability, and for performance :
Thomas F. O'Connell wrote: > On Feb 6, 10:33 am, t...@sss.pgh.pa.us (Tom Lane) wrote: > > "Thomas F. O'Connell" <t...@o.ptimized.com> writes: > > > > > but we just built 8.2.2 from source using cc, and now we're seeing > > > this type of error in the logs: > > > ERROR: attribute 3 has wrong type > > > DETAIL: Table has type character varying, but query expects > > > character varying. > > > > This has nothing to do with your compiler :-( > > I just wanted to eliminate that variable. It took me a while to track > down the source of the error in the source. > > I saw this nearby thread on -hackers: > > http://archives.postgresql.org/pgsql-hackers/2007-02/msg00276.php > > The tables in question generating these errors in this database do > indeed have functional indexes. Is there a known fix, or does this > qualify as a bug? It is a bug. There is a patch committed to CVS, and we are working to figure out how to distribute this fix. -- Bruce Momjian bruce@momjian.us Homepage http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +