On Thu, Jun 16, 2011 at 02:52, Craig Ringer <cr...@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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
