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

On 16/06/2011 2:47 PM, Magnus Hagander wrote:

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

In this case a different (or additional) string for EDB releases is
exactly what I'm after - a string that uniquely identifies a release
made with an EDB installer, so that "8.4.2-1" can be reliably identified
as separate from "8.4.2-2" and separate again from a hand-built Pg or a
.zip release.

Maybe an attribute other than File Version can be used, as custom
attributes can IIRC be defined easily.

That said, it turns out it doesn't matter much if you have a proper
symbols cache maintained by symstore.exe . It just figures it out based
on the hash of the binary, so you don't need to know exactly what
release you're using.

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

Well, they're already in the installer bundles. It'd just be nice to
have an easily browsed directory of all the old versions, one that
didn't require downloading and unpacking the installer for that version.

To download 8.4.2-2 at all I had to go to download the latest EDB
release, note the URL and play substitution games. Maybe I just didn't
find the "old versions" link that'll turn out to be lurking somewhere.

Again, though, a proper symbols server would pretty much take care of
this problem.

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

Oops.

The Microsoft symbol server serves over HTTP and I hadn't noticed that
the proposed method in that article was SMB as I was rushing off to work
when I finished that post.

It looks like running your own symbol over http is simple, though. Just
expose the directory tree created by symstore.exe over http. No
Windows-specific stuff required. I just tested it out with a local
Apache instance and it works fine.

Most instructions talk about symproxy.exe but it turns out you don't
need that unless you want to run a proxy for Microsoft's symbol server.
That's is undesirable and unnecessary in a public symbol server.

It'd be pretty trivial to rsync a copy of the symbols directory created
by symstore.exe from the build host over to a public web server, so
offering an http symbol server looks quite painless.

As for adding the symbols, that just needs to be part of the release
process, such that an EDB release can't get to the download page without
first having had its symbols added to the store.

The Windows "symstore" command from Debugging Tools for Windows is
requried to update the symbol store. It's invoked as:

C:\Program Files\PostgreSQL\8.4>symstore add /s
"C:\Users\Craig\Developer\PgSymbols" /t PostgreSQL /v "9.0.0-1"
/compress /r /f "C:\Program Files\PostgreSQL\9.0"

to store to a local symbol store C:\Users\Craig\Developer\PgSymbols . If
used for a public server that would be a local or UNC path to a
directory that was getting rsync'd to a public web server instead.

--
Craig Ringer

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