Re: Replication identifiers, take 4
От | Petr Jelinek |
---|---|
Тема | Re: Replication identifiers, take 4 |
Дата | |
Msg-id | 5517302C.6080007@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Replication identifiers, take 4 (Petr Jelinek <petr@2ndquadrant.com>) |
Ответы |
Re: Replication identifiers, take 4
|
Список | 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 по дате отправления: