R: Per-server univocal identifier - Mailing list pgsql-hackers

From Giampaolo Tomassoni
Subject R: Per-server univocal identifier
Date
Msg-id NBBBIHMOBLOHKCGIMJMDAEJGFHAA.g.tomassoni@libero.it
Whole thread Raw
In response to Re: Per-server univocal identifier  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
> I assume by 'univocal' you mean unequivocal.

Yes, sorry about that: I'm writing italish...


> Can you set it up in a table per server? or in a file? or would you
> rather use a guuid?

A per-server table will probably be my way.


> And how is this to be made available?

Well, a function would be fine.


> And is it to be unique per machine, or per cluster (since you can have
> many postgresql clusters on one machine).

If it is a per-machine discriminator, it will be a per-node discriminator as well...

Also, it will be useful to people not running a cluster (like me), since they only need a multi-master capability on a
tablefor a legacy app... 


> cheers
>
> andrew

Cheers,

giampaolo


>
> Giampaolo Tomassoni wrote:
>
> >Dears,
> >
> >I'm looking for a way to univocally identify the server on which
> a sql function or statement is running. My idea would be
> something close to the value returned by a 'host -f' under linux:
> the FQDN of the host, but even a serial code or a number would be
> fine to me. It needs only to be immutable, I guess.
> >
> >I know there is something suitable under Oracle and, even worse,
> under mysql...
> >
> >The purpose is mostly related to a light replication problem I
> have, in which I need to 'emulate' a multi-master replication on a table.
> >
> >I placed a question on the IRC list and I found a couple of
> unreplied messages asking the same thing in the pgsql-general list.
> >
> >
> >
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>                http://archives.postgresql.org



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Per-server univocal identifier
Next
From: Greg Stark
Date:
Subject: Re: Rethinking stats communication mechanisms