Re: SIGSEGV taken on 8.1 during dump/reload

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Gregory Maxwell <gmaxwell(at)gmail(dot)com>
Subject: Re: SIGSEGV taken on 8.1 during dump/reload
Date: 2005-11-12 15:47:35
Message-ID: 27762.1131810455@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> So the idea is to force failure when it would otherwise succeed, not
> just for the pretty error messages but for stability of the system.

Exactly. Peter's right that we'd not always get a "nice" error message
--- but it's not hard to figure out "unresolved symbol" failures.
As we just were reminded, it can be really hard to figure out minor
incompatibilities with wrong-version libraries, and the real point of
the proposal is to save us from going through *that* again.

> I would be in favour if storing the CATALOG_VERSION in the pg_finfo
> struct and rejecting anything that doesn't match.

Not sure that CATALOG_VERSION is an amazingly useful thing to use.
I think the major version number (eg "8.1") would be sufficient,
and it'd certainly give error messages that meant more to the casual
user.

The problem with CATALOG_VERSION is that we bump it basically for
changes in the on-disk contents of a freshly initdb'd database, which
does not have all that much to do with the ABI seen by a shared library.
To have something useful that is finer-grain than major version number,
I think we'd need to invent a separate version number that could be
bumped whenever we made incompatible changes in in-memory structures
or function APIs. Which'd be almost every day during development :-(
I don't think it's worth trying to do that. People who work with
development tip should know to recompile their libraries whenever they
recompile the main system.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-11-12 15:53:55 Re: How to find a number of connections
Previous Message Tom Lane 2005-11-12 15:34:14 Re: CONNECT BY PRIOR