Symbols and versioning of binary releases; running a symbol server

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Symbols and versioning of binary releases; running a symbol server
Date: 2011-06-16 00:52:12
Message-ID: 4DF953BC.5080603@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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?

It's always possible to get the user to send their symbols directory, or
to just debug it locally using windbg.exe, but it'd be really nice if it
were easier to reliably match releases to symbol sets.

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 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.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

Responses

Browse pgsql-general by date

  From Date Subject
Next Message sunpeng 2011-06-16 02:27:55 Re: You could be a PostgreSQL Patch Reviewer!
Previous Message Tom Lane 2011-06-15 23:42:44 Re: = ANY (SELECT ..) and type casts, what's going on here?

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2011-06-16 00:54:49 Re: Commitfest 2011-6 is underway! Reviewers needed.
Previous Message Alvaro Herrera 2011-06-16 00:08:09 Re: creating CHECK constraints as NOT VALID