Re: version() output vs. 32/64 bits

It has been pointed out to me that the output of the version() function
is becoming more confusing in face of mixed 32/64 bit environments.
Output like i486-pc-linux-gnu just says what kind of kernel the build
environment has, not whether you actually have a IA-32 build.
Conversely, amd64-pc-linux-gnu could very well be a 32-bit build.
Solaris similar issues. Moreover, there does not actually seem to be a
way to find out whether you have a 32-bit or a 64-bit build (except by
using OS tools).

I'm not quite sure yet how to address this. Do others have similar
experiences or certain information requirements? Other ideas?

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> ... Moreover, there does not actually seem to be a
> way to find out whether you have a 32-bit or a 64-bit build (except by
> using OS tools).

I think the basic definition of "32 bit" or "64 bit", certainly for
our purposes, is sizeof(void *). That is something that configure
could easily find out. Or you could look at sizeof(size_t) which
it already does find out.

I have no immediate proposal on how to factor that into the version
string.

regards, tom lane

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > ... Moreover, there does not actually seem to be a
> > way to find out whether you have a 32-bit or a 64-bit build (except by
> > using OS tools).
>
> I think the basic definition of "32 bit" or "64 bit", certainly for
> our purposes, is sizeof(void *). That is something that configure
> could easily find out. Or you could look at sizeof(size_t) which
> it already does find out.
>
> I have no immediate proposal on how to factor that into the version
> string.

I think the pointer size is part of the compiler, rather than the
platform, so it should go after the compiler mention, e.g.:

test=> select version();
version
--------------------------------------------------------------------------

PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
(1 row)

The attached patch modifies configure.in and updates a documentation mention.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Tom Lane wrote:
>> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>>> ... Moreover, there does not actually seem to be a
>>> way to find out whether you have a 32-bit or a 64-bit build (except by
>>> using OS tools).
>> I think the basic definition of "32 bit" or "64 bit", certainly for
>> our purposes, is sizeof(void *). That is something that configure
>> could easily find out. Or you could look at sizeof(size_t) which
>> it already does find out.
>>
>> I have no immediate proposal on how to factor that into the version
>> string.
>
> I think the pointer size is part of the compiler, rather than the
> platform, so it should go after the compiler mention, e.g.:
>
> test=> select version();
> version
> --------------------------------------------------------------------------
>
> PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
> (1 row)
>
> The attached patch modifies configure.in and updates a documentation mention.

You forgot a certain another build system ;-)

Should be trivial to add there though, if we choose to do it this way,
so that's not an objection in general.

//Magnus

On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
> Tom Lane wrote:
> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > > ... Moreover, there does not actually seem to be a
> > > way to find out whether you have a 32-bit or a 64-bit build (except by
> > > using OS tools).
> >
> > I think the basic definition of "32 bit" or "64 bit", certainly for
> > our purposes, is sizeof(void *). That is something that configure
> > could easily find out. Or you could look at sizeof(size_t) which
> > it already does find out.
> >
> > I have no immediate proposal on how to factor that into the version
> > string.
>
> I think the pointer size is part of the compiler, rather than the
> platform, so it should go after the compiler mention, e.g.:

I'm not really sure about that.

> test=> select version();
> version
>
> --------------------------------------------------------------------------
>
> PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
> (1 row)

Maybe we should separate all that, e.g.,

SELECT version(); => 'PostgreSQL 8.4devel'
SELECT pg_host_os(); => 'bsdi4.3.1'
SELECT pg_host_cpu(); => 'i386' (although this is still faulty, as per my
original argument; needs some thought)
SELECT pg_compiler(); => 'GCC 2.95.3'
SELECT pg_pointer_size(); => 4 (or 32) (this could also be a SHOW variable)

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
>> PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit

> Maybe we should separate all that, e.g.,

> SELECT version(); => 'PostgreSQL 8.4devel'
> SELECT pg_host_os(); => 'bsdi4.3.1'
> SELECT pg_host_cpu(); => 'i386' (although this is still faulty, as per my
> original argument; needs some thought)
> SELECT pg_compiler(); => 'GCC 2.95.3'
> SELECT pg_pointer_size(); => 4 (or 32) (this could also be a SHOW variable)

Seems like serious overkill. No one has asked for access to individual
components of the version string, other than the PG version number
itself, which we already dealt with.

I didn't actually see a user request for finding out the pointer width,
either, but if there is one then Bruce's proposal seems fine.

regards, tom lane

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
> >> PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
>
> > Maybe we should separate all that, e.g.,
>
> > SELECT version(); => 'PostgreSQL 8.4devel'
> > SELECT pg_host_os(); => 'bsdi4.3.1'
> > SELECT pg_host_cpu(); => 'i386' (although this is still faulty, as per my
> > original argument; needs some thought)
> > SELECT pg_compiler(); => 'GCC 2.95.3'
> > SELECT pg_pointer_size(); => 4 (or 32) (this could also be a SHOW variable)
>
> Seems like serious overkill. No one has asked for access to individual
> components of the version string, other than the PG version number
> itself, which we already dealt with.

Maybe we could have a separate function which returned the info in
various columns (OUT params). Maybe it would be useful to normalize the
info as reported the buildfarm, which right now is a bit ad-hoc.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
> >> PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
>
> > Maybe we should separate all that, e.g.,
>
> > SELECT version(); => 'PostgreSQL 8.4devel'
> > SELECT pg_host_os(); => 'bsdi4.3.1'
> > SELECT pg_host_cpu(); => 'i386' (although this is still faulty, as per my
> > original argument; needs some thought)
> > SELECT pg_compiler(); => 'GCC 2.95.3'
> > SELECT pg_pointer_size(); => 4 (or 32) (this could also be a SHOW variable)
>
> Seems like serious overkill. No one has asked for access to individual
> components of the version string, other than the PG version number
> itself, which we already dealt with.
>
> I didn't actually see a user request for finding out the pointer width,
> either, but if there is one then Bruce's proposal seems fine.

It is true no one asked for this information except Peter (I assume for
just academic reasons), and I don't think we care from a bug reporting
perspective, so I will just keep the patch around in case we ever want it.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Tom Lane wrote:

> > I didn't actually see a user request for finding out the pointer width,
> > either, but if there is one then Bruce's proposal seems fine.
>
> It is true no one asked for this information except Peter (I assume for
> just academic reasons),

Huh, count us (Command Prompt) as another requestor, and not for
academic reasons (in case that adds value to the vote).

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Wednesday 31 December 2008 18:22:50 Bruce Momjian wrote:
> It is true no one asked for this information except Peter (I assume for
> just academic reasons),

no

Hello

2008/12/31 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Tom Lane wrote:
>> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> > On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
>> >> PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
>>
>> > Maybe we should separate all that, e.g.,
>>
>> > SELECT version(); => 'PostgreSQL 8.4devel'
>> > SELECT pg_host_os(); => 'bsdi4.3.1'
>> > SELECT pg_host_cpu(); => 'i386' (although this is still faulty, as per my
>> > original argument; needs some thought)
>> > SELECT pg_compiler(); => 'GCC 2.95.3'
>> > SELECT pg_pointer_size(); => 4 (or 32) (this could also be a SHOW variable)
>>
>> Seems like serious overkill. No one has asked for access to individual
>> components of the version string, other than the PG version number
>> itself, which we already dealt with.
>
> Maybe we could have a separate function which returned the info in
> various columns (OUT params). Maybe it would be useful to normalize the
> info as reported the buildfarm, which right now is a bit ad-hoc.
>

All should be GUC read only variables - It is cheep.

regards
Pavel Stehule

> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2008/12/31 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
>> Maybe we could have a separate function which returned the info in
>> various columns (OUT params). Maybe it would be useful to normalize the
>> info as reported the buildfarm, which right now is a bit ad-hoc.

> All should be GUC read only variables - It is cheep.

Not as cheap as a single added function. If we need to provide these
fields broken out --- and no one has demonstrated any need to do so ---
then I'd support Alvaro's suggestion.

regards, tom lane

On Wed, Dec 31, 2008 at 01:25:34PM -0500, Tom Lane wrote:
> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> > 2008/12/31 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> >> Maybe we could have a separate function which returned the info
> >> in various columns (OUT params). Maybe it would be useful to
> >> normalize the info as reported the buildfarm, which right now is
> >> a bit ad-hoc.
>
> > All should be GUC read only variables - It is cheep.
>
> Not as cheap as a single added function. If we need to provide
> these fields broken out --- and no one has demonstrated any need to
> do so --- then I'd support Alvaro's suggestion.

+1 for broken-out fields in columns per Alvaro.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Bruce Momjian píše v st 31. 12. 2008 v 11:22 -0500:
> Tom Lane wrote:
> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > > On Wednesday 31 December 2008 04:45:01 Bruce Momjian wrote:
> > >> PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
> >
> > > Maybe we should separate all that, e.g.,
> >
> > > SELECT version(); => 'PostgreSQL 8.4devel'
> > > SELECT pg_host_os(); => 'bsdi4.3.1'
> > > SELECT pg_host_cpu(); => 'i386' (although this is still faulty, as per my
> > > original argument; needs some thought)
> > > SELECT pg_compiler(); => 'GCC 2.95.3'
> > > SELECT pg_pointer_size(); => 4 (or 32) (this could also be a SHOW variable)
> >
> > Seems like serious overkill. No one has asked for access to individual
> > components of the version string, other than the PG version number
> > itself, which we already dealt with.
> >
> > I didn't actually see a user request for finding out the pointer width,
> > either, but if there is one then Bruce's proposal seems fine.
>
> It is true no one asked for this information except Peter (I assume for
> just academic reasons), and I don't think we care from a bug reporting
> perspective, so I will just keep the patch around in case we ever want it.

I'm sorry for late response, I was offline for last week. Current
Solaris packages use 32/64bit information. See following output:

postgres=# select version();

version
----------------------------------------------------------------------------------------------
PostgreSQL 8.3.5 64-bit on i386-pc-solaris2.11, compiled
by /opt/SUNWspro.40/SS12/bin/cc -Xa

The information about 32/64bit is important, because both versions are
available, but for some reason they not have same features enabled (e.g.
PL/pgPerl is not in 64bit version). These difference are described in
the special man page and users need to easily determine which version is
running.

Zdenek

Alvaro Herrera píše v st 31. 12. 2008 v 12:54 -0300:

> Maybe we could have a separate function which returned the info in
> various columns (OUT params). Maybe it would be useful to normalize the
> info as reported the buildfarm, which right now is a bit ad-hoc.

+1 it sounds good.

Zdenek

Zdenek Kotala wrote:
>
> Alvaro Herrera p??e v st 31. 12. 2008 v 12:54 -0300:
>
> > Maybe we could have a separate function which returned the info in
> > various columns (OUT params). Maybe it would be useful to normalize the
> > info as reported the buildfarm, which right now is a bit ad-hoc.
>
> +1 it sounds good.

So what do we want to do for 8.4? Add 32/64-bit version() indicator and
add OUT parameters to the TODO list?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> So what do we want to do for 8.4? Add 32/64-bit version() indicator and
> add OUT parameters to the TODO list?

+1. There seems a good case for making the 32/64bit distinction
visible somewhere, and the text version string is as good as anyplace.

I think the business about splitting up the string is mostly
lily-gilding, but if someone wants it enough to do it ...

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > So what do we want to do for 8.4? Add 32/64-bit version() indicator and
> > add OUT parameters to the TODO list?
>
> +1. There seems a good case for making the 32/64bit distinction
> visible somewhere, and the text version string is as good as anyplace.

OK, done with the attached patch, and autoconf run. Magnus, would you
add this change to the MSVC build? Thanks.

test=> select version();
version
--------------------------------------------------------------------------

PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
(1 row)

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>>> So what do we want to do for 8.4? Add 32/64-bit version() indicator and
>>> add OUT parameters to the TODO list?
>> +1. There seems a good case for making the 32/64bit distinction
>> visible somewhere, and the text version string is as good as anyplace.
>
> OK, done with the attached patch, and autoconf run. Magnus, would you
> add this change to the MSVC build? Thanks.
>
> test=> select version();
> version
> --------------------------------------------------------------------------
>
> PostgreSQL 8.4devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3, 32-bit
> (1 row)
>
>

Done.

postgres=# select version();
version
----------------------------------------------------------------
PostgreSQL 8.4devel, compiled by Visual C++ build 1400, 32-bit
(1 row)

//Magnus

On Wed, 31 Dec 2008, Tom Lane wrote:

> No one has asked for access to individual components of the version
> string, other than the PG version number itself, which we already dealt
> with.

I think I'm now up to having wrote something to break apart the output
from version() into individual fields for 3 different companies. If
you're got a bunch of database servers on a network, it seems inevitable
that eventually you'll end up collecting information about them via
queries against port 5432 for managing everything, and the output from
version() always ends up on that hotlist. I'd bet the only reason this
hasn't been a specific TODO request before is because it is relatively
easy (albeit fragile) to parse it out manually.

There are also some use cases related to writing tuning tools, where for
example the platform bit size determines what range some settings can
reach. Again, you can just parse it out if that starts being included,
but it would be cleaner to grab just that one piece. (Right now I just
look at the maximum value for one of the settings I know changes size to
figure that out when this pops up)

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Greg Smith wrote:
> I think I'm now up to having wrote something to break apart the output
> from version() into individual fields for 3 different companies. If
> you're got a bunch of database servers on a network, it seems inevitable
> that eventually you'll end up collecting information about them via
> queries against port 5432 for managing everything, and the output from
> version() always ends up on that hotlist.

Good point, but if you want to do reasonable monitoring, don't you also
want information on CPU, disk, etc.? So really, you need shell access
anyway. Plus, my point was the the version output isn't all that
reliable anyway, because it tells you about the build system and build
compiler, not the host system and host compiler (if any). I think it's
tempting but not terribly practical.

> There are also some use cases related to writing tuning tools, where for
> example the platform bit size determines what range some settings can
> reach. Again, you can just parse it out if that starts being included,
> but it would be cleaner to grab just that one piece. (Right now I just
> look at the maximum value for one of the settings I know changes size to
> figure that out when this pops up)

That was one reason why people approached me to raise this subject. But
after consideration, I think it is much better to actually query the
maximum values directly rather than trying to reverse engineer them from
platform information.