Re: pg_system_identifier()
| От | Fujii Masao |
|---|---|
| Тема | Re: pg_system_identifier() |
| Дата | |
| Msg-id | CAHGQGwH5K9Dm+td00AE9Gwby92fzOJC4mXcjgerYtq+GqxUZhw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_system_identifier() (Michael Paquier <michael.paquier@gmail.com>) |
| Ответы |
Re: pg_system_identifier()
|
| Список | 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 по дате отправления: