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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Allowing extended stats on foreign and partitionedtables
Следующее
От: Andreas Karlsson
Дата:
Сообщение: Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)