Re: share library version problems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bryan White <bryan(at)arcamax(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: share library version problems
Date: 2006-08-22 21:09:51
Message-ID: 11723.1156280991@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Bryan White <bryan(at)arcamax(dot)com> writes:
> I am having problems with my libpq programs crashing. This seems to be
> a version incompatibility and I want to find out how to best proceed.

> My main database is running Fedora Core 5 with the supplied PostgreSQL
> 8.1.4.

> My web server is running Fedora Core 4 with the supplied PostgreSQL 8.0.8.

> My dev server was running the same setup as the web server. The
> difference is that it acts as its own database server. I was
> uncomfortable running an older version of the server on my test system
> then on the live system. So yesterday I removed the OS supplied
> PostgreSQL RPMs and installed 8.1.4 from RPMs on the PostgreSQL download
> site.

> Today I discovered that programs that I compile on my dev server will
> segfault when run on the live web server.

Can you get a core dump and provide a gdb backtrace from the segfault?
Right offhand I see no difference in the claimed API of 8.0 and 8.1
libpq except that 8.1 adds lo_create(), which I suppose you're not
using. So while this isn't good practice in general, I don't see
why it wouldn't work in this particular case.

One thing you should check is whether both libs were built with the same
options (compare pg_config --configure output from the 8.0 and 8.1
installations).

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2006-08-22 21:21:12 Re: using deferred initially deferred to solve foreign key checking issues
Previous Message Martijn van Oosterhout 2006-08-22 21:00:03 Re: share library version problems