Alena Rybakina <a.rybak...@postgrespro.ru> writes: > After starting the server (initdb + pg_ctl start) I ran a regress test > create_misc.sql ('\i src/test/regress/sql/create_misc.sql') and, after > that, > I ran the fdw test ('\i contrib/postgres_fdw/sql/postgres_fdw.sql') in > the psql, and it failed in the core-dump due to the worked assert. > To be honest, such a failure occurred only if the fdw extension was not > installed earlier.
Thanks for the report! This can be reproduced more simply with z=# create table test (a int, b text) partition by list(a); CREATE TABLE z=# merge into test using (select 1, 'foo') as source on (true) when matched then do nothing; server closed the connection unexpectedly The MERGE produces a query tree with :rtable ( {RANGETBLENTRY :alias <> :eref {ALIAS :aliasname test :colnames ("a" "b") } :rtekind 0 :relid 49152 :relkind p :rellockmode 3 :tablesample <> :perminfoindex 1 :lateral false :inh true :inFromCl false :securityQuals <> } ... ) :rteperminfos ( {RTEPERMISSIONINFO :relid 49152 :inh true :requiredPerms 0 :checkAsUser 0 :selectedCols (b) :insertedCols (b) :updatedCols (b) } ) and that zero for requiredPerms is what leads to the assertion failure later. So I'd blame this on faulty handling of the zero-partitions case in the RTEPermissionInfo refactoring. (I didn't bisect to prove that a61b1f748 is exactly where it broke, but I do see that the query successfully does nothing in v15.) regards, tom lane