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 17:24:34
Message-ID: 20051112172430.GC571@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 12, 2005 at 12:03:00PM -0500, Tom Lane wrote:
> That would be attractive if we could get it to happen without the
> assumption that the library uses PG_FUNCTION_INFO_V1 ... but if it still
> needs that assumption, it doesn't seem like much of an improvement.
> It's not always easy for people to see dynamic-linker error messages,
> so I'd rather the message were issued under our control when possible.

If you want something that works even if people don't use
PG_FUNCTION_INFO_V1, you need something like the linux kernel source
does. During the main build the kernel generate a vmmagic.o object.
This defines a number of symbols including a block containing flags
about endianness, spinlocks, etc. Any module expecting to be loaded
needs to link it in. While loading you simply memcmp() the block with
what you're expecting and fail if it doesn't match.

Note, this is significantly more finegrained, in that it can pickup
descrepicies in HAVE_INT64_TIMESTAMP, NAMEDATALEN, INDEX_MAX_KEYS, etc.
The kind of things that currently appear in pg_controldata. In the
future maybe a 32/64 bit flag.

If we don't like imposing link time constraints, we could require
people to include:

#ifdef PG_MAGIC_BLOCK
PG_MAGIC_BLOCK;
#endif

In any one of their source files and put the definition in a header
file somewhere. This may be even better.

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:44:23 Re: SIGSEGV taken on 8.1 during dump/reload
Previous Message Tom Lane 2005-11-12 17:03:00 Re: SIGSEGV taken on 8.1 during dump/reload