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


Reply via email to