From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, chris(at)replicon(dot)com |
Subject: | Database system identifier via SELECT |
Date: | 2013-02-27 23:57:34 |
Message-ID: | 512E9D6E.3000207@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Regarding these prior threads:
http://www.postgresql.org/message-id/CAC2SuRJLMtKyvCs6DbxdyUrHy+WKe-94cBuGnwCXAg914cwG7g@mail.gmail.com
http://www.postgresql.org/message-id/200707101624.47885.peter_e@gmx.net
It's somewhat less than pretty, but you *can* simply:
select substring(pg_read_binary_file('global/pg_control'),1,8);
then, knowing whether the system is little- or big-endian, decode the
resulting hex representation of a uint64 however you find to be
convenient, like say:
#!/usr/bin/python
import struct
import sys
print struct.unpack("Q", sys.argv[1].decode("hex"))[0]
... or your preferred spelling in C/Perl/LOLCode/whatever.
For many purposes the raw hex representation will be sufficient in any case.
The main downside here is the requirement of a superuser connection.
It'd be fairly trivial (and a lot saner) to write an extension to expose
GetSystemIdentifier() via SQL. Unfortunately that won't work for my
purposes because I need something that'll work on potentially quite old
servers and with minimal intrusiveness, but it'd be a reasonable answer
for people who want it for cluster/replication management.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2013-02-28 03:16:00 | issue with cpluspluscheck and systemtap |
Previous Message | Boszormenyi Zoltan | 2013-02-27 19:38:29 | Re: Strange Windows problem, lock_timeout test request |