Date: Sun, 15 Jan 2023 10:24:49 -0600
From: Justin Pryzby <pryzby@telsasoft.com>
To: v.davydov@postgrespro.ru
Cc: pgsql-hackers@lists.postgresql.org, tgl@sss.pgh.pa.us
Subject: Re: UPDATE operation terminates logical replication receiver process
 due to an assertion
Message-ID: <20230115162449.GE9837@telsasoft.com>
References: <d259d69652b8c2ff50e14cda3c236c7f@postgrespro.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d259d69652b8c2ff50e14cda3c236c7f@postgrespro.ru>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://www.postgresql.org/message-id/20230115162449.GE9837%40telsasoft.com>
Precedence: bulk

On Thu, Jan 12, 2023 at 01:23:57PM +0300, v.davydov@postgrespro.ru wrote:
> Dear all,
> 
> I think I've found a problem in logical replication that was introduced
> recently in the patch:
> 
> Fix calculation of which GENERATED columns need to be updated
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=3f7836ff651ad710fef52fa87b248ecdfc6468dc

> There is an assertion which accidentally terminates logical replication
> worker process. The assertion was introduced in the patch. To reproduce the
> problem Postgres should be compiled with enabled assertions. The problem
> appears when executing UPDATE operation on a non-empty table with GENERATED
> columns and a BEFORE UPDATE trigger. The problem seems to appear on the
> latest snapshots of 13 and 14 versions (sorry, I haven't tested other
> versions).
> 
> Stack:
> ------
> TRAP: FailedAssertion("relinfo->ri_GeneratedExprs != NULL", File: "execUtils.c", Line: 1292)

Yeah, confirmed under master branch and v15.

Tom ?

-- 
Justin