Re: Symbols and versioning of binary releases; running a symbol server

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Symbols and versioning of binary releases; running a symbol server
Date: 2011-06-16 06:47:32
Message-ID: BANLkTimKjn-o40BCimVxXHgwZxWZ+aMr+g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Thu, Jun 16, 2011 at 02:52, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> wrote:
> Hi (EnterpriseDB) folks
>
> I've been working with someone off list to get some information about a
> crash they encounter during a batch run. We're generating a crash dump, but
> I'm having some issues getting matching symbols so I can examine it.
>
> One thing that would help with this would be if the EnterpriseDB releases
> included their build revision in the output of "SELECT version()", so it's
> always clear exactly what build is in use.
>
> I've also noticed in this process that the "File version" on postgres.exe
> bears no apparent relationship to the EnterpriseDB release number. For
> example, postgresql 8.4.2-2 has a File Version of 8.4.2-104 while 8.4.2-1
> has a file version of (IIRC) 8.4.2-9343 . Is there any way that can be
> improved?

1) This is not actually an EnterpriseDB thing - those versions and
stamps are set by the build system
2) Why -general, and not -hackers? ;) I'll move it...

To get to your points:

The last digit of the version number is actually the build *day*. It's
calculated by the formula:
my $d = ($year - 100) . "$yday";

I have a feeling we've overflowed that field. The value today
should'äve been 11166. I think we overflowed it when the year turned
2000, without noticing! The docs claim it's a 16 bit integer though,
which should've worked.

We could (once we've figured out why it's wrong) put that number in
the version string as well. Or some other number - if we can pick a
good one.

I don't think the EDB installers should have a *different* string than
what you'd get if you built the same thing manually...

> Even better would be to put zipped symbols directories onto the EDB download
> site, arranged by Pg version. Bonus points for having symlinks from the

Or right alongside the downloads themselves.

> md5sum of postgres.exe to the matching symbols. Better again would be to run
> a public symbol server with symbols for all builds EnterpriseDB releases:
>
> http://chadaustin.me/2009/03/reporting-crashes-in-imvu-creating-your-very-own-symbol-server/
>
> ... so there's no need to play version guessing games, you just point your
> debugger at the symbol server and it fetches what it needs on demand.
>
> Come to think of it, I can probably run a public symbol server myself if the
> EDB folks don't want to, but it'd be lovely if they were willing to do so
> because it could be integrated into the release process to ensure symbols
> were never missing for a build that hit public release.

Hmm. That site talks about sharing them over a windows fileshar,e I
doubt anybody wants to do that publically.

Now, if this can be made to serve off a simple http (or ftp) server,
we could probably run a server for it off the infrastructure - but
that's assuming someone actually uploads the symbols as builds are
created ;) And it requires the server not to be windows, and using
simple protocols...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mike Christensen 2011-06-16 06:50:11 Re: Constraint to ensure value does NOT exist in another table?
Previous Message Simon Riggs 2011-06-16 06:36:40 Re: Constraint to ensure value does NOT exist in another table?

Browse pgsql-hackers by date

  From Date Subject
Next Message Radosław Smogura 2011-06-16 07:12:24 [Streaming] Datum compression
Previous Message Tom Lane 2011-06-16 05:11:35 Re: [WIP] Support for "ANY/ALL(array) op scalar" (Was: Re: Boolean operators without commutators vs. ALL/ANY)