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

From: Greg Stark <stark(at)mit(dot)edu>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Marti Raudsepp <marti(at)juffo(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, David Fetter <david(at)fetter(dot)org>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table
Date: 2014-04-27 01:52:27
Message-ID: CAM-w4HMfuov1ox5S85HAwJqp-0nCy4TbgY79TBrNLXSJ_r=q_A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 26, 2014 at 8:58 PM, Josh Berkus <josh(at)agliodbs(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-04-27 02:42:47 Should pg_stat_bgwriter.buffers_backend_fsync be removed?
Previous Message Stephen Frost 2014-04-27 01:36:28 Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD