Есть много баз данных, все связываются с центральной, чтоб не запутаться в них даже в случае восстановления из бекапов

rovan,

когда у клиента разворачиваешь базу с нуля, у почти всех oid будет 16385 +- 1

хотелось бы уникальный идентификатор кластера, который создается случайно в момент установки(например время установки), тогда его можно было бы использовать в паре с OID базы данных.

У меня просто так получается, сделал бэкап бд у клиента, принес куда ни будь, развернул, а он возьми и подключись к центру...

ЫЧто и в какой момент должен идентифицировать ваш идентификатор?

идентифицировать надо конкретный экземпляр базы данных, чтобы центр мог определить случайные и посторонние копии

ЫЯ правильно понимаю, что развернутая из бэкапа база должна получить отличный от оригинала идентификатор?

правильно

лопатанаверное в бекапе должна лежать непроинициализированнная БД -- тогда концы сойдутся -- развернутая из бекапа БД, к которой было совершено [инициализирующее] обращение -- далее по тексту.

гарантий тут не будет никаких, но гарантия сверхмалой вероятности может дать генерация гуид при первом обращении инициирующей процедурки.
(есть вроде набор утилит в виде http://www.postgresql.org/docs/9.4/static/uuid-ossp.html )

вариант реализации -- любое обращение читает из некоторой таблички запись констант, а если ее (записи) нет -- создает с опорой на сгенерированный гуид (и вешает блокирующий триггер на все события записи и таблицы). работает, если в бекапе этой записи гарантированно не будет. если кто-то обратится к бд--шаблону по пользовательским интерфейсам -- то проинициализирует её -- и придётся чистить перед бекапированием "шаблона"


такой гуид есть, а ели его нет то при первом обращении создается, но и в бекап он тоже попадает, на этом как раз я и прокололся, и решил заморочится

лопатаа чтобы не подключаться куда не надо, если такой забывачивый, -- надо все обращения завернуть в WHERE client_inet_addr() blahblahblah UND server_inet_addr() blahblahblah , ну и усложнить жизнь жесткими ограничениями listen_addresses [postgres.conf]и hosts in pg_hba.conf


базы географически разнесены, ip динамические, к каждой базе подключаются несколько клиентов, без ограничений, любой клиент может подключатся к центру.

лопатано дешевле -- не забывать


цена ошибки очень велика, минимум день реставрации БД

надеялся что есть что ни будь штатное

svd85надеялся что есть что ни будь штатное

как в оракле http://www.sql.ru/forum/49760/data-sozdaniya-bazy-dannyh

наверное попробую что то типа
http://www.sql.ru/forum/1003712/kak-uznat-vremya-modifikacii-bd

или придется сделать привязку к железу