Re: Symbols and versioning of binary releases; running a symbol server - Mailing list pgsql-general

From Magnus Hagander
Subject Re: Symbols and versioning of binary releases; running a symbol server
Date
Msg-id BANLkTimKjn-o40BCimVxXHgwZxWZ+aMr+g@mail.gmail.com
Whole thread Raw
In response to Symbols and versioning of binary releases; running a symbol server  (Craig Ringer <craig@postnewspapers.com.au>)
List pgsql-general
On Thu, Jun 16, 2011 at 02:52, Craig Ringer <craig@postnewspapers.com.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/

pgsql-general by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Constraint to ensure value does NOT exist in another table?
Next
From: Mike Christensen
Date:
Subject: Re: Constraint to ensure value does NOT exist in another table?