Re: [HACKERS] Different table schema in logical replication crashes
От | Petr Jelinek |
---|---|
Тема | Re: [HACKERS] Different table schema in logical replication crashes |
Дата | |
Msg-id | 4292ecc5-ff32-8da8-9030-79bf02cf5544@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Different table schema in logical replication crashes (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Different table schema in logical replication crashes
Re: [HACKERS] Different table schema in logical replication crashes |
Список | pgsql-hackers |
On 14/04/17 17:33, Peter Eisentraut wrote: > On 4/14/17 08:49, Petr Jelinek wrote: >>> Are we prepared to support different schemas in v10? Or should we >>> disallow it for v10 and add a TODO? >>> >> >> Ah nuts, yes it's supposed to be supported, we seem to not initialize >> cstate->range_table in tablesync which causes this bug. The CopyState >> struct is private to copy.c so we can't easily set cstate->range_table >> externally. I wonder if tablesync should just construct CopyStmt instead >> of calling the lower level API. > > Maybe pass the range_table to BeginCopyFrom so that it can write it into > cstate? > I tried something bit different which seems cleaner to me - use the pstate->r_table instead of ad-hock locally made up range table and fill that using standard addRangeTableEntryForRelation. Both in tablesync and in DoCopy instead of the old coding. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: