Re: pg_system_identifier() - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: pg_system_identifier()
Date
Msg-id CAHGQGwH5K9Dm+td00AE9Gwby92fzOJC4mXcjgerYtq+GqxUZhw@mail.gmail.com
Whole thread Raw
In response to Re: pg_system_identifier()  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: pg_system_identifier()
List pgsql-hackers
On Mon, Aug 26, 2013 at 1:12 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Mon, Aug 26, 2013 at 7:47 AM, Jim Nasby <jim@nasby.net> wrote:
>> On 8/23/13 11:23 AM, Greg Stark wrote:
>>>
>>> This doesn't generate a unique id. You could back up a standby and restore
>>> it and point it at the original master and end up with two standbies with
>>> the same id.
>>
>>
>> If you want to enforce something unique throughout a cluster, I think we're
>> stuck with having the cluster communicate IDs across an entire cluster.
>> AFAIK that's how both Slony and londiste 3 do it.
> The same applies to Postgres-XC for node identifiers. Users can adapt
> the settings of their cluster to their own needs.
>
>> I think it's also noteworthy that Slony and londiste both rely on the user
>> specifying node identifiers. They don't try to be magic about it. I think
>> there's 2 advantages there:
>>
>> - Code is simpler
>> - Users can choose a naming schema that makes sense for them
> Definitely agreed on that.

A user can already specify the unique standby name by using
application_name in primary_conninfo. So, the remaining thing
that we should do is to expose the primary_conninfo, i.e.,
commit the merge-recovery.conf-into-postgresql.conf patch ;P

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: median and percentile function implementation
Next
From: Heikki Linnakangas
Date:
Subject: pg_dump/restore encoding woes