Re: SIGSEGV taken on 8.1 during dump/reload

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 16:49:27
Message-ID: 20051112164927.GB571@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 12, 2005 at 11:18:51AM -0500, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > Sure, CATALOG_VERSION isn't that useful, but it's the only thing in the
> > header files that gives any kind of indication what version you're
> > compiling against. PG_VERSION is a string, which diminishes its
> > usefulness considerably.
>
> How so? All we care about is being able to (1) compare for equality,
> and (2) print out something useful in error messages. I claim that
> PG_VERSION does #1 equally well and #2 better.

I was thinking of compile time. The compiler can compare
CATALOG_VERSION in #if statements, but it can't compare strings. Trying
to make a module that compiles against several different versions of
postgres requires testing against CATALOG_VERSION because there's
nothing else.

However, if we purely want distinguish between major releases in the
loading of modules (thus implying no ABI changes between 8.1.0 and
8.1.7), then PG_VERSION will do fine.

Another way that doesn't require code changes would be to make a dummy symbol
containing the version and referring to it in pg_finfo. Then you'd get
error messages like: Couldn't find symbol 'PG_version_verify_8_1'. i.e.
let the dynamic linker do the work.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-11-12 17:03:00 Re: SIGSEGV taken on 8.1 during dump/reload
Previous Message Tom Lane 2005-11-12 16:18:51 Re: SIGSEGV taken on 8.1 during dump/reload