Re: Using non-sequential timelines in order to help with possible collisions

On Wed, Jul 19, 2017 at 11:23 AM, Brian Faherty
<anothergenericuser(at)gmail(dot)com> wrote:
> Hey hackers,
> I was working with replication and recovery the other day and noticed that
> there were scenarios where I could cause multiple servers to enter the same
> timeline while possibly having divergent data. One such scenario is Master A
> and Replica B are both on timeline 1. There is an event that causes Replica
> B to become promoted which changes it to timeline 2. Following this, you
> perform a restore on Master A to a point before the event happened. Once
> Postgres completes this recovery on Master A, it will switch over to
> timeline 2. There are now WAL files that have been written to timeline 2
> from both servers.
>
> From this scenario, I would like to suggest considering using non-sequential
> timelines. From what I have investigated so far, I believe the *.history
> files in the WAL directory already have all the timelines id's in them and
> are in order. If we could make those timeline ids to be a bit more
> unique/random, and still rely on the ordering in the *.history file, I think
> this would help prevent multiple servers on the same timeline with divergent
> data.
>
> I was hoping to begin a conversation on whether or not non-sequential
> timelines are a good idea before I looked at the code around timelines.

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company