Subject: Re: adding partitioned tables to publications
To: Amit Langote <amitlangote09@gmail.com>
References: 
 <CA+HiwqH=Y85vRK3mOdjEkqFK+E=ST=eQiHdpj43L=_eJMOOznQ@mail.gmail.com>
 <ff6007b3-02c2-8296-2896-db99a51f57e2@2ndquadrant.com>
 <CA+HiwqGWXeBA2xagkz_YdxycmO38Vah_aviyJf_kC_kjCdL-Xg@mail.gmail.com>
 <CA+HiwqGkknVb+ccLVkgw1DoBYPzpuR43L+aT1eOT8dVEtiedtw@mail.gmail.com>
 <bb9427bd-9da9-68f6-108e-d1b21aa5a307@2ndquadrant.com>
 <CA+HiwqFA6V1QKLnHjyrVUBiDF4+K0U8MvymWWgkv4uWgeUfQrQ@mail.gmail.com>
 <CA+HiwqE2-6U=XzsBZ9efzPatFDgrgGybBEj7vm-kUQL8DM4BWw@mail.gmail.com>
 <64a2c1c7-3887-787b-e43b-ac15112bda82@2ndquadrant.com>
 <CA+HiwqGVmZtdwDrGy3ak-k5V=QGH6kpb46aKOtpbt3R57RPwFA@mail.gmail.com>
 <CA+HiwqEThKQh6bPOj68fqUO3s+PRBdUeAfe5GGDgoYdU_fb2Sw@mail.gmail.com>
 <f4a265b3-e1e4-4367-c7db-57fac0a26545@2ndquadrant.com>
 <CA+HiwqGKsb1S1GgvdCsvOmOgva=W1fAb8eAYHhLePinUf+XwKQ@mail.gmail.com>
 <21de0e53-0f5f-f31a-2dcb-6e4b35571c94@2ndquadrant.com>
 <CA+HiwqFyydvQ5g=qa54UM+Xjm77BdhX-nM4dXQkNOgH=zvDjoA@mail.gmail.com>
 <CA+HiwqEf_bZbiUXTanwbrTUbtN1hXb0s1orokXALKMNSs3E=pw@mail.gmail.com>
Cc: Petr Jelinek <petr@2ndquadrant.com>,
 Rafia Sabih <rafia.pghackers@gmail.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <04d78603-edae-9243-9dde-fe3037176a7d@2ndquadrant.com>
Date: Thu, 9 Apr 2020 09:14:01 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
 <CA+HiwqEf_bZbiUXTanwbrTUbtN1hXb0s1orokXALKMNSs3E=pw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2020-04-09 05:39, Amit Langote wrote:
> sub_viaroot ERROR:  number of columns (2601) exceeds limit (1664)
> sub_viaroot CONTEXT:  slot "sub_viaroot", output plugin "pgoutput", in
> the change callback, associated LSN 0/1621010

I think the problem is that in maybe_send_schema(), 
RelationClose(ancestor) releases the relcache entry, but the tuple 
descriptors, which are part of the relcache entry, are still pointed to 
by the tuple map.

This patch makes the tests pass for me:

diff --git a/src/backend/replication/pgoutput/pgoutput.c 
b/src/backend/replication/pgoutput/pgoutput.c
index 5fbf2d4367..cf6e8629c1 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -305,7 +305,7 @@ maybe_send_schema(LogicalDecodingContext *ctx,

         /* Map must live as long as the session does. */
         oldctx = MemoryContextSwitchTo(CacheMemoryContext);
-       relentry->map = convert_tuples_by_name(indesc, outdesc);
+       relentry->map = 
convert_tuples_by_name(CreateTupleDescCopy(indesc), 
CreateTupleDescCopy(outdesc));
         MemoryContextSwitchTo(oldctx);
         send_relation_and_attrs(ancestor, ctx);
         RelationClose(ancestor);

Please check.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services