Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table
Дата
Msg-id CAM-w4HMfuov1ox5S85HAwJqp-0nCy4TbgY79TBrNLXSJ_r=q_A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Sat, Apr 26, 2014 at 8:58 PM, Josh Berkus <josh@agliodbs.com> wrote:
> However, there's a fundamental problem with the concept of the dataset
> ID in that there's absolutely no way for PostgreSQL to know when it has
> a unique dataset.  Consider a downtime database file cloning for
> example; the two databases would have the same identifier and yet both
> be standalones which quickly diverge.  So I haven't thought of a good
> solution to that.

If you're content to use random numbers then you could generate one
from system entropy on every startup. If you generated a new timeline
for every startup then the pair of system id and random startup id
(which would be the new timelineid) would let you look at any two
instances and determine if they're related and where they diverged
even if it was from a database clone.

I don't think MAC address or other hardware identifiers really saves
you from using system entropy anyways. You might very well install a
clone on the same machine and in an environment like Heroku you could
very easily end up restoring a database onto the same VM twice
entirely by accident. I actually think using /dev/urandom is a better
idea than depending on things like MAC address almost always.

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Should pg_stat_bgwriter.buffers_backend_fsync be removed?