From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: What is happening on buildfarm member dugong |
Date: | 2007-09-11 16:08:53 |
Message-ID: | 6127.1189526933@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Sergey E. Koposov" <math(at)sai(dot)msu(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2007-09-11 16:15:21 | Re: invalidly encoded strings |
Previous Message | Sergey E. Koposov | 2007-09-11 15:40:36 | Re: What is happening on buildfarm member dugong |