Re: Replication identifiers, take 4

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Steve Singer <steve(at)ssinger(dot)info>
Cc: pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: Replication identifiers, take 4
Date: 2015-03-28 22:50:20
Message-ID: 5517302C.6080007@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

So I did some more in depth look, I do have couple of comments.

I would really like to have something like "Logical Replication
Infrastructure" doc section that would have both decoding and
identifiers (and possibly even CommitTs) underneath.

There is typo in docs:
> + <para>
> + The optional <function>filter_by_origin_cb</function> callback
> + is called to determine wheter data that has been replayed

wheter -> whether

And finally I have issue with how the new identifiers are allocated.
Currently, if you create identifier 'foo', remove identifier 'foo' and
create identifier 'bar', the identifier 'bar' will have same id as the
old 'foo' identifier. This can be problem because the identifier id is
used as origin of the data and the replication solution using the
replication identifiers can end up thinking that data came from node
'bar' even though they came from the node 'foo' which no longer exists.
This can have bad effects for example on conflict detection or debugging
problems with replication.

Maybe another reason to use standard Oids?

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2015-03-28 22:53:29 Re: PATCH: pgbench - merging transaction logs
Previous Message Tom Lane 2015-03-28 22:37:04 Re: compute_index_stats is missing a CHECK_FOR_INTERRUPTS