Re: Running the fdw test from the terminal crashes into the core-dump

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Running the fdw test from the terminal crashes into the core-dump
Дата
Msg-id 3895487.1708283600@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Running the fdw test from the terminal crashes into the core-dump  (Alena Rybakina <a.rybakina@postgrespro.ru>)
Ответы Re: Running the fdw test from the terminal crashes into the core-dump  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Patch: Add parse_type Function
Следующее
От: "Andrey M. Borodin"
Дата:
Сообщение: Re: Transaction timeout