Re: What is happening on buildfarm member dugong - Mailing list pgsql-hackers

From Tom Lane
Subject Re: What is happening on buildfarm member dugong
Date
Msg-id 6127.1189526933@sss.pgh.pa.us
Whole thread Raw
In response to Re: What is happening on buildfarm member dugong  ("Sergey E. Koposov" <math@sai.msu.ru>)
Responses Re: What is happening on buildfarm member dugong
List 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 by date:

Previous
From: "Sergey E. Koposov"
Date:
Subject: Re: What is happening on buildfarm member dugong
Next
From: Jeff Davis
Date:
Subject: Re: invalidly encoded strings