On Wed, Jul 19, 2017 at 8:05 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paqu...@gmail.com> writes: >> On Wed, Jul 19, 2017 at 7:00 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> It's interesting that you bring this up. I've also wondered why we >>> don't use random TLIs. I suppose I'm internally assuming that it's >>> because the people who wrote the code are far more brilliant and >>> knowledgeable of this area than I could ever be and that doing >>> anything else would create some kind of awful problem, but maybe >>> that's not so. > >> I am not the only who worked on that, but the result code is a tad >> more simple, as it is possible to guess more easily some hierarchy for >> the timelines, of course with the history files at hand. > > Yeah, right now you have the ability to guess that, say, timeline 42 > is a descendant of 41, which you couldn't assume with random TLIs. > Also, the values are only 32 bits, which is not wide enough to allow > imagining that random() could be relied on to produce non-duplicate > values.
pg_backend_random() perhaps? If any new code uses random(), those would be slashed quickly at review. > If we had separate database identifiers for slave installations, which > AFAIR we don't, it'd be possible to consider incorporating part of > the server ID into timeline IDs it creates, which would alleviate > Brian's issue I think. That is, instead of 1, 2, 3, ..., a server > might create 1xyz, 2xyz, 3xyz, ... where "xyz" are random digits > associated with the particular installation. This is obviously > not bulletproof since you could have collisions of the xyz's, but > it would help. Also you could imagine allowing DBAs to assign > distinct xyz codes to every slave in a given community. I am not much into any concept of complicating the timeline name to be honest :) Having a unique identifier per node has value for other purposes, like clustering, and we would have the same information by adding in the history file the ID of the node that generated the new timeline. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
