| From: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Different table schema in logical replication crashes |
| Date: | 2017-04-15 01:36:18 |
| Message-ID: | 4292ecc5-ff32-8da8-9030-79bf02cf5544@2ndquadrant.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| Attachment | Content-Type | Size |
|---|---|---|
| Set-range-table-for-CopyFrom-in-tablesync.patch | text/plain | 4.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andreas Karlsson | 2017-04-15 01:44:18 | Re: Cutting initdb's runtime (Perl question embedded) |
| Previous Message | Peter Eisentraut | 2017-04-14 23:57:30 | Re: Allowing extended stats on foreign and partitioned tables |