Re: race condition in pg_class - Mailing list pgsql-hackers

From Noah Misch
Subject Re: race condition in pg_class
Date
Msg-id 20240704220816.51.nmisch@google.com
Whole thread Raw
In response to Re: race condition in pg_class  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: race condition in pg_class
List pgsql-hackers
On Thu, Jul 04, 2024 at 08:00:00AM +0300, Alexander Lakhin wrote:
> 28.06.2024 08:13, Noah Misch wrote:
> > Pushed. ...
> 
> Please look also at another anomaly, I've discovered.
> 
> An Assert added with d5f788b41 may be falsified with:
> CREATE TABLE t(a int PRIMARY KEY);
> INSERT INTO t VALUES (1);
> CREATE VIEW v AS SELECT * FROM t;
> 
> MERGE INTO v USING (VALUES (1)) AS va(a) ON v.a = va.a
>   WHEN MATCHED THEN DO NOTHING
>   WHEN NOT MATCHED THEN DO NOTHING;
> 
> TRAP: failed Assert("resultRelInfo->ri_TrigDesc"), File: "nodeModifyTable.c", Line: 2891, PID: 1590670

Thanks.  When all the MERGE actions are DO NOTHING, view_has_instead_trigger()
returns true, so we use the wholerow code regardless of the view's triggers or
auto update capability.  The behavior is fine, so I'm fixing the new assertion
and comments with new patch inplace087-merge-DO-NOTHING-v8.patch.  The closest
relevant tests processed zero rows, so they narrowly avoided witnessing this
assertion.

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Wrong results with grouping sets
Next
From: Michael Paquier
Date:
Subject: Re: pgsql: Add pg_get_acl() to get the ACL for a database object