Re: seawasp failing, maybe in glibc allocator

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: seawasp failing, maybe in glibc allocator
Дата
Msg-id alpine.DEB.2.22.394.2105122028010.1107467@pseudo
обсуждение исходный текст
Ответ на Re: seawasp failing, maybe in glibc allocator  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: seawasp failing, maybe in glibc allocator  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
> Possibly I have just added "ulimit -c unlimited" in the script, we should see 
> the effect on next round.

for def5b065 it ended on on the contrib ltree test:

  2021-05-12 20:12:52.528 CEST [3042602:410] pg_regress/ltree LOG: disconnection: session time: 0:00:13.426
user=buildfarm database=contrib_regression_ltree host=[local]
 

  /home/fabien/pg/build-farm-12/buildroot/HEAD/pgsql.build/contrib/ltree/results/ltree.out
  2021-05-12 20:12:52.523330311 +0200
  @@ -7931,11 +7931,8 @@
   (1 row)

   SELECT count(*) FROM _ltreetest WHERE t ~ '1.1.1.*' ;
  - count
  --------
  -    19
  -(1 row)
  -
  +ERROR:  stack depth limit exceeded
  +HINT:  Increase the configuration parameter "max_stack_depth" (currently  2048kB), after ensuring the platform's
stackdepth limit is adequate.
 
   SELECT count(*) FROM _ltreetest WHERE t ~ '*.1' ;
    count
   -------

Not a core dump, though.

-- 
Fabien.



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Some other CLOBBER_CACHE_ALWAYS culprits
Следующее
От: David Steele
Дата:
Сообщение: Always bump PG_CONTROL_VERSION?