Re: [GENERAL] Symbols and versioning of binary releases; running a symbol server - Mailing list pgsql-hackers

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/