Subject: show precise repos version for dev builds?

From: Fabien COELHO <[email-masked]>
Date: Sun, 1 Oct 2017 10:14:23 +0200 (CEST)

Hello,

I use postgres "11devel" packages kindly distributed on 
"apt.postgresql.org" and recompiled every few hours.

I wanted to know which version it was, and "11devel" is kind of imprecise.

Ok, there is a hint in the deb package name:

 	11~~devel~20170930.2214-1~87.git2632bcc.pgdg16.04+1

But this information does not seem to be available from the executables 
themselves:

   sh> psql --version
   psql (PostgreSQL) 11devel

   sh> pgbench --version
   pgbench (PostgreSQL) 9.6.5

Some projects provide a repository or build date information:

   sh> clang --version
   clang version 6.0.0 (trunk 314585)

   sh> gcc --version
   gcc (GCC) 8.0.0 20170930 (experimental)

With some svn project I use "svnversion" which shows a summary of the 
status, eg "5432M" which tells that the sources are locally modified
from version 5432.

I would find it useful to have something like that in pg as well, and I 
have not found it available.

ISTM that extending the version name with the commit id and or date in 
some version output, eg "11devel [2632bcc 2017-09-30 ...]", would do it.

Thoughts?

-- 
Fabien.

-- 
Sent via pgsql-hackers mailing list ([email-masked])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

---

From: Tom Lane <[email-masked]>
Date: Sun, 01 Oct 2017 11:10:02 -0400

Fabien COELHO <[email-masked]> writes:
> ...

configure --with-extra-version=whateveryouwant

			regards, tom lane

---

From: Fabien COELHO <[email-masked]>
Date: Sun, 1 Oct 2017 18:13:02 +0200 (CEST)

Hello,

> configure --with-extra-version=whateveryouwant

Thanks for the pointer!

So now I have to convince the apt.postgresql.org people to build the devel 
version with this trick.

-- 
Fabien.

---

From: Jeremy Schneider <[email-masked]>
Date: Tue, 10 Oct 2017 20:44:39 -0700

> configure --with-extra-version=whateveryouwant

I see that this build option has been around since 9.4; is anyone
using it to mark patched production builds?  EnterpriseDB or
2ndQuadrant? How about the cloud providers?

-Jeremy

-- 
http://about.me/jeremy_schneider

---

From: Craig Ringer <[email-masked]>
Date: Wed, 11 Oct 2017 16:19:56 +0800

> 2ndQuadrant? How about the cloud providers?

We started using it for BDR, but unfortunately too much software
explodes spectacularly when you use it, due to simplistic/buggy
version parsing.

This led me to push for wider adoption of server_version_num - in
particular, exposing it as an initial connection parameter via
GUC_REPORT, and exposing it in pg_config. After a few attempts I've
given up on that as a lost cause now, though I still disagree with the
rationale.

Right now, if you use it, various 3rd party software will fail in a
variety of exciting ways, some more subtle than others.

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

---

From: Jeremy Schneider <[email-masked]>
Date: Wed, 11 Oct 2017 13:28:26 -0700

> explodes spectacularly when you use it, due to simplistic/buggy

Since 10.0 will break most of that software anyway, maybe this is a
good time to revisit the question?  :)

-J

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 11 Oct 2017 18:46:19 -0400

> explodes spectacularly when you use it, due to simplistic/buggy

I've been using

--with-extra-version=+git`date +%Y%m%d`"~"`git rev-parse --short HEAD`

for my local builds for some time, and I've not experienced any such
problems.

However, using the various numeric reporting options is clearly better
if you want to do version comparisons.  The "extra version" stuff should
be mainly for labeling.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

---

From: Craig Ringer <[email-masked]>
Date: Thu, 12 Oct 2017 09:27:11 +0800

> for my local builds for some time, and I've not experienced any such

Interesting.

I've seen issues with a number of tools. The one I can remember most
clearly is check_postgres.pl . Nobody's going to argue that this is
pretty code, but last time I tested (9.4-era, admittedly) it exploded
messily with extra-version.

> if you want to do version comparisons.  The "extra version" stuff should

The trouble there is that we lack numeric version in some (IMO
crucial) places where we only have the string version:

- In the startup packet. We send server_version, but not
server_version_num, as GUC_REPORT. So if a client wants
server_version_num it has to do another round trip to query for it.

- In pg_config, where we don't expose any --version-num only --version.

---

From: Tom Lane <[email-masked]>
Date: Wed, 11 Oct 2017 22:48:22 -0400

> messily with extra-version.

FWIW, Salesforce tried to do something similar to Peter's example
while I was there.  It did not work as well as we'd hoped :-( because
what got baked into the built executables was the latest git commit hash
as of the time you'd last run configure, not what was current as of the
latest "make".  Not to mention that you might have built from an
uncommitted state.  We tried to find a fix for the former problem that
didn't create lots of overhead, without much success.  No idea what
to do about the latter.

These are not big problems for package-building since you basically
never distribute executables that don't get built from a clean state.
But they put a crimp in the usefulness of the idea for developers.

			regards, tom lane

---

From: Fabien COELHO <[email-masked]>
Date: Thu, 12 Oct 2017 22:50:47 +0200 (CEST)

Hello Tom,

> didn't create lots of overhead, without much success.

My 0.02€:

For a research project we regenerate a header file with a string 
containing the working copy status information,

  // file version.h
  #define REV "<version-output>"

and there is a very small C file which is recompiled with a constant 
string based on the version:

  // version.c
  #include "version.h"
  const char * version = REV;

The make dependencies ensure that the header file is regenerated on each 
build with a phony target, and the C file is thus recompiled and linked 
into the executables on each build. It means that all executables are 
linked on each rebuild, even if not necessary, though.

> No idea what to do about the latter.

"svnversion" adds a "M" for modified on the status. There is an option 
with "git describe" to get something similar:

     git describe --long --always --all --dirty

Also there is a need of a fall back if this fails, to get "<unknown 
version>" instead.

---

From: Andres Freund <[email-masked]>
Date: Thu, 12 Oct 2017 13:55:55 -0700

Hi,

On 2017-10-12 22:50:47 +0200, Fabien COELHO wrote:
> build with a phony target, and the C file is thus recompiled and linked into
> the executables on each build. It means that all executables are linked on
> each rebuild, even if not necessary, though.

That'd be quite painful, consider e.g. people using LTO.  If done right
however, that should be avoidable to some degree. When creating the
version file, only replace its contents if the contents differ - that's
just a few lines of scripting.

Greetings,

Andres Freund

---

From: Fabien COELHO <[email-masked]>
Date: Fri, 13 Oct 2017 16:17:07 +0200 (CEST)

> just a few lines of scripting.

Indeed.

A potential issue is with dynamic linking, potentially someone could 
recompile/reinstall just one shared object or dll, and the executable 
using the lib would change its behavior, and run with libs from 
heterogeneous version. What is the actual version? Hard to say.

In dev mode we often use static linking so that we can copy the executable 
for a previous version and it would not change depending on updated libs, 
and so that we always know (or should know) what actual version is 
running.

-- 
Fabien.

---

From: Robert Haas <[email-masked]>
Date: Fri, 13 Oct 2017 15:47:03 -0400

On Thu, Oct 12, 2017 at 4:50 PM, Fabien COELHO <[email-masked]> wrote:
> "svnversion" adds a "M" for modified on the status. There is an option with
> "git describe" to get something similar:
>

I tried this out a bit:

[rhaas pgsql]$ git describe --long --always --all --dirty
heads/master-0-gd133982d59
[rhaas pgsql]$ git checkout head~
...blah blah...
[rhaas pgsql]$ git describe --long --always --all --dirty
heads/x-218-g6393613b6a

Eh, what?  Hmm, maybe it's because I have a local branch called 'x'
lying around from something or other.

[rhaas pgsql]$ git branch -D x
Deleted branch x (was 77b6b5e9ce).
[rhaas pgsql]$ git describe --long --always --all --dirty
tags/REL_10_BETA3-458-g6393613b6a

Mmph.  I understand the desire to identify the exact commit used for a
build somehow, but something whose output depends on whether or not I
left a branch lying around locally doesn't seem that great.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

---

From: Michael Paquier <[email-masked]>
Date: Sat, 14 Oct 2017 08:50:33 +0900

> left a branch lying around locally doesn't seem that great.

Similarly to Peter, I prefer a minimum amount of information so I tend
to just use `git rev-parse --short HEAD` with --extra-version for my
own builds. Looking at the timestamp of the files installed is enough
to know when you worked on them, and when testing a patch and
committing it on a local branch before compiling you can know easily
where you left things off. git branch --contains is also useful to get
from which branch is commit from.
-- 
Michael

---

From: Fabien COELHO <[email-masked]>
Date: Sat, 14 Oct 2017 07:25:06 +0200 (CEST)

Hello Robert,

> left a branch lying around locally doesn't seem that great.

Indeed, the branch/tag search might have a little strange behavior.

Probably you would be more happy with just the commit (--always) & knowing 
that it was changed (--dirty).

  sh> git describe --always --dirty
  b81eba6

  sh> vi README
  # edit

  sh> git describe --always --dirty
  b81eba6-dirty

-- 
Fabien.