Re: Replication identifiers, take 4 - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: Replication identifiers, take 4
Date
Msg-id 5517302C.6080007@2ndquadrant.com
Whole thread Raw
In response to Re: Replication identifiers, take 4  (Petr Jelinek <petr@2ndquadrant.com>)
Responses Re: Replication identifiers, take 4  (Andres Freund <andres@anarazel.de>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: compute_index_stats is missing a CHECK_FOR_INTERRUPTS
Next
From: Jeff Janes
Date:
Subject: Re: proposal: row_to_array function