Yeah, it would be easy enough to write a custom extension to do it. I was hoping for something built-in so I wouldn't require a pre-req extension be installed on all servers by the superuser....sysadmins tend to resist making such changes. But oh well what you gotta do you gotta do....thanks guys.
On Thu, Dec 8, 2011 at 3:09 PM, Safari Code
<safaricode@gmail.com> wrote:
You can get the database system identifier from the OS shell as part of the control data: pg_controldata /Library/PostgreSQL/9.1/data
Here, '/Library/PostgreSQL/9.1/data' is my data directory on os x; replace it with your own data directory.
From there, you can isolate the database system identifier with grep:
pg_controldata /Library/PostgreSQL/9.1/data | grep "system identifier"
This is not the same as calling a function within a SELECT statement, but using the shell command above, one could easily write a function that returns the database system identifier as a string in a SQL query.
I hope this solves the problem.
On Thu, Dec 8, 2011 at 4:57 PM, Scott Mead
<scottm@openscg.com> wrote:
On Thu, Dec 8, 2011 at 4:27 PM, Bruce Momjian
<bruce@momjian.us> wrote:
Joshua D. Drake wrote:
>
> On 12/08/2011 12:57 PM, Bruce Momjian wrote:
> >
> > Chris Redekop wrote:
> >> Is there any way to get the database system identifier via a select
> >> statement? I have a primary/secondary async replication setup, and I'd
> >> like be able to verify from the client side that the provided primary and
> >> secondary connection strings do in fact refer to the same data set...
> >
> > Wow, that is a reasonable thing to want available via SQL, but I can't
> > see a way to get to it.
> >
> > The only method I can suggest is to write a server-side C function that
> > calls GetSystemIdentifier().
select inet_server_addr()?
--Scott
>
> This seems like something we should have in core, don't you think?
Yeah, kind of, except this is the first request we ever got for this.
The identifier is passed as part of streaming replication, so maybe it
will be needed more in the future.