Re: UPDATE operation terminates logical replication receiver process due to an assertion

2023-01-15 Thread Tom Lane 
Justin Pryzby  writes:
> On Sun, Jan 15, 2023 at 01:25:11PM -0500, Tom Lane wrote:
>> v15?  That assert is from 8bf6ec3ba, which wasn't back-patched.

> The assert isn't from 8bf6 (Improve handling of inherited GENERATED
> expressions.), but rather:

> commit 3f7836ff651ad710fef52fa87b248ecdfc6468dc

Ah.  I jumped to the wrong conclusion after failing to reproduce
on v15, but I must've fat-fingered the test case somehow.

regards, tom lane

Re: UPDATE operation terminates logical replication receiver process due to an assertion

2023-01-15 Thread Justin Pryzby 
On Sun, Jan 15, 2023 at 01:25:11PM -0500, Tom Lane wrote:
> Justin Pryzby  writes:
> > On Thu, Jan 12, 2023 at 01:23:57PM +0300, v.davy...@postgrespro.ru wrote:
> >> TRAP: FailedAssertion("relinfo->ri_GeneratedExprs != NULL", File: 
> >> "execUtils.c", Line: 1292)
> 
> > Yeah, confirmed under master branch and v15.
> 
> v15?  That assert is from 8bf6ec3ba, which wasn't back-patched.

I misspoke, and had actually reproduced under master and v14:

TRAP: FailedAssertion("relinfo->ri_GeneratedExprs != NULL", File: 
"execUtils.c", Line: 1336, PID: 25692)

The assert isn't from 8bf6 (Improve handling of inherited GENERATED
expressions.), but rather:

commit 3f7836ff651ad710fef52fa87b248ecdfc6468dc
Author: Tom Lane 
Date:   Thu Jan 5 14:12:17 2023 -0500

Fix calculation of which GENERATED columns need to be updated.

And in v14: 
commit 8cd190e13a22dab12e86f7f1b59de6b9b128c784
Author: Tom Lane 
Date:   Thu Jan 5 14:12:17 2023 -0500

Fix calculation of which GENERATED columns need to be updated.

-- 
Justin

Re: UPDATE operation terminates logical replication receiver process due to an assertion

2023-01-15 Thread Tom Lane 
Justin Pryzby  writes:
> On Thu, Jan 12, 2023 at 01:23:57PM +0300, v.davy...@postgrespro.ru wrote:
>> TRAP: FailedAssertion("relinfo->ri_GeneratedExprs != NULL", File: 
>> "execUtils.c", Line: 1292)

> Yeah, confirmed under master branch and v15.

v15?  That assert is from 8bf6ec3ba, which wasn't back-patched.

regards, tom lane

Re: UPDATE operation terminates logical replication receiver process due to an assertion

2023-01-15 Thread Tom Lane 
Justin Pryzby  writes:
> Yeah, confirmed under master branch and v15.
> Tom ?

Yeah, sorry, I've been absorbed in $other_stuff.  Will look
at this soon.  My guess is that this logrep code path is
missing the necessary setup operation.

regards, tom lane

Re: UPDATE operation terminates logical replication receiver process due to an assertion

2023-01-15 Thread Justin Pryzby 
On Thu, Jan 12, 2023 at 01:23:57PM +0300, v.davy...@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