Alena Rybakina <a.rybakina@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