Re: What is happening on buildfarm member dugong
От | Tom Lane |
---|---|
Тема | Re: What is happening on buildfarm member dugong |
Дата | |
Msg-id | 6127.1189526933@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: What is happening on buildfarm member dugong ("Sergey E. Koposov" <math@sai.msu.ru>) |
Ответы |
Re: What is happening on buildfarm member dugong
|
Список | pgsql-hackers |
"Sergey E. Koposov" <math@sai.msu.ru> writes: > Actually, in the log file I also see some messages about has_seq_search: > =EB=EF=ED=E1=EE=E4=E1: CREATE DATABASE "contrib_regression" TEMPLATE=3Dtem= > plate0 > NOTICE: database "contrib_regression" does not exist, skipping > ERROR: too many active hash_seq_search scans > ERROR: too many active hash_seq_search scans > ERROR: too many active hash_seq_search scans > ERROR: too many active hash_seq_search scans > ERROR: could not fsync segment 0 of relation 1663/16384/2617: No such file= > or directory > ERROR: checkpoint request failed That could be a consequent effect I think --- bgwriter is lacking an AtEOXact_HashTables call in error recovery (something I will go fix) and so after enough fsync errors we'd start getting these. Anyway it seems we need to cast the net a bit wider for where the troublesome Assert is. I'd suggest rebuilding the whole system with --enable-cassert, then comment out the USE_ASSERT_CHECKING #define in pg_config.h, and "make clean/make" in one backend subdirectory at a time till you see where it stops failing. Then repeat at the file level. Divide and conquer... regards, tom lane
В списке pgsql-hackers по дате отправления: