Re: pglogical 2.3.2 on 9.4 --> 12.3 CONFLICT: remote DELETE (tuple not found). Resolution: skip.
От | milist ujang |
---|---|
Тема | Re: pglogical 2.3.2 on 9.4 --> 12.3 CONFLICT: remote DELETE (tuple not found). Resolution: skip. |
Дата | |
Msg-id | CACG9ogxOs4B0P83rCP-2EFtuj1RipJP=_QCsJ1fQwq8cms=ycQ@mail.gmail.com обсуждение исходный текст |
Ответ на | pglogical 2.3.2 on 9.4 --> 12.3 CONFLICT: remote DELETE (tuple not found). Resolution: skip. (milist ujang <ujang.milist@gmail.com>) |
Список | pgsql-general |
replication identity correctly displayed on detail after resolution message:
LOG: CONFLICT: remote DELETE on relation public.a_XXXX replica identity index a_XXX_pk (tuple not found). Resolution: skip.
pk_col_1[varchar]:ZZZ100008 pk_col_2[bpchar]:12 pk_col_3[bpchar]:G << this is oldval
status_data[varchar]:(null)} in xact origin=2,timestamp=2020-08-12 08:06:33.956683+08,commit_lsn=0/CA6499D0
I am curious about bpchar in log DETAILS.
Is it the correct error message for the data type char?
On Wed, Aug 12, 2020 at 10:50 AM milist ujang <ujang.milist@gmail.com> wrote:
Configured pglogical source is 9.4 target is 12.3a table has PK from multiple column (varchar(50),char(2),char(1)).initial syncronization is OK, but when at source there is delete , but got error at target...LOG: CONFLICT: remote DELETE on relation public.a_XXXX replica identity index a_XXX_pk (tuple not found). Resolution: skip.replica identity was set to default for the table so yes there is old image on those 3 columns:but why delete was error at target?collation exactly same on all GUC.any direction to print debug verbosity on why delete on target didnt find row and skipped?--regards
ujang jaenudin | DBA Consultant (Freelancer)
http://ora62.wordpress.com
http://id.linkedin.com/pub/ujang-jaenudin/12/64/bab
regards
ujang jaenudin | DBA Consultant (Freelancer)
http://ora62.wordpress.com
http://id.linkedin.com/pub/ujang-jaenudin/12/64/bab
ujang jaenudin | DBA Consultant (Freelancer)
http://ora62.wordpress.com
http://id.linkedin.com/pub/ujang-jaenudin/12/64/bab
В списке pgsql-general по дате отправления: