Date: Mon, 12 Jul 2021 10:53:01 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Rahila Syed <rahilasyed90@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Column Filtering in Logical Replication
Message-ID: <202107121453.fnxj3xee3jkp@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <fe1e52c0-ae22-119f-c382-9579033b83a6@enterprisedb.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202107121453.fnxj3xee3jkp%40alvherre.pgsql>
Precedence: bulk

On 2021-Jul-12, Tomas Vondra wrote:

> FWIW "make check" fails for me with this version, due to segfault in
> OpenTableLists. Apparenly there's some confusion - the code expects the
> list to contain PublicationTable nodes, and tries to extract the
> RangeVar from the elements. But the list actually contains RangeVar, so
> this crashes and burns. See the attached backtrace.
> 
> I'd bet this is because the patch uses list of RangeVar in some cases
> and list of PublicationTable in some cases, similarly to the "row
> filtering" patch nearby. IMHO this is just confusing and we should
> always pass list of PublicationTable nodes.

+1 don't make the code guess what type of list it is.  Changing all the
uses of that node to deal with PublicationTable seems best.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Cuando no hay humildad las personas se degradan" (A. Christie)