SEO

Can one of the Windows buildfarm owners please try building and running
"make check" by hand rather than using the buildfarm script? It looks
like they all stopped reporting around the same time, and this might
give us a better clue about when things fall over.

Also, if you're up for it, please try reversing this patch, which looks
innocuous enough, but is the only thing I can see in the relevant time
period that looks at all suspicious:
http://archives.postgresql.org/pgsql...7/msg00256.php

cheers

andrew


-------- Original Message --------
Subject: RE: Build farm on Windows
Date: Fri, 28 Jul 2006 13:53:18 +1000
From: Phil Cairns <phil@pagaros.com.au>
To: 'Andrew Dunstan' <andrew@dunslane.net>



Hi Andrew, this is yak calling from Australia.

I think I have a problem here with the HEAD build. The last few times I've
run the build, it has sat in "make check" for a long time (well over an
hour). According to the Task Manager, postmaster.exe is taking most of this
time, and it also seems to be leaking memory. After about an hour of running
today, postmaster.exe is using about 100MB of RAM, and is still busily
firing off instances of postgres.exe.

The process is hard to kill as well. It doesn't respond to a Ctrl+C in the
MSYS window, so I kill it by stopping postmaster.exe from within the Task
Manager, and it cleans things up from there.

Does this sound like something wrong with my setup? I'm pretty sure I
haven't changed anything since my last successful run 3 days ago.

All the best,
Phil.



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Stefan Kaltenbrunner wrote:
> Andrew Dunstan wrote:
>
>> Can one of the Windows buildfarm owners please try building and running
>> "make check" by hand rather than using the buildfarm script? It looks
>> like they all stopped reporting around the same time, and this might
>> give us a better clue about when things fall over.
>>
>> Also, if you're up for it, please try reversing this patch, which looks
>> innocuous enough, but is the only thing I can see in the relevant time
>> period that looks at all suspicious:
>> http://archives.postgresql.org/pgsql...7/msg00256.php
>>
>
> will see what i can do(it definitly hangs in make check here too) - but
> this issue seem to kill my box up to the point where it is impossible to
> login(!) and i have to hard-reboot it.
> Looks like it is churning CPU like mad when that happens ...
>
>
>

Does it get past the initdb stage? Past db startup? Past creating the
regression db? Run any tests and report results?

cheers

andrew


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

The TimeZone changes are looking might suspicious ...

cheers

andrew

Stefan Kaltenbrunner wrote:
> Andrew Dunstan wrote:
>
>> Can one of the Windows buildfarm owners please try building and running
>> "make check" by hand rather than using the buildfarm script? It looks
>> like they all stopped reporting around the same time, and this might
>> give us a better clue about when things fall over.
>>
>> Also, if you're up for it, please try reversing this patch, which looks
>> innocuous enough, but is the only thing I can see in the relevant time
>> period that looks at all suspicious:
>> http://archives.postgresql.org/pgsql...7/msg00256.php
>>
>
>
> looks like the postmaster fails to startup up:
>
> ./pg_regress --temp-install=./tmp_check --top-builddir=../../..
> --temp-port=55678 --schedule=./parallel_schedule --multibyte=SQL_ASCII
> --load-language=plpgsql
> ============== removing existing temp installation ==============
> ============== creating temporary installation ==============
> ============== initializing database system ==============
> ============== starting postmaster ==============
>
> pg_regress: postmaster did not start within 60 seconds
> Examine ./log/postmaster.log for the reason
> make[2]: *** [check] Error 2
> make[2]: Leaving directory
> `/home/pgbuild/pgfarmbuild/HEAD/pgsql.1436/src/test/regress'
> make[1]: *** [check] Error 2
> make[1]: Leaving directory
> `/home/pgbuild/pgfarmbuild/HEAD/pgsql.1436/src/test'
> make: *** [check] Error 2
>
>
>
> and the logfile is full of:
>
>
> FATAL: failed to initialize timezone_abbreviations to "Default"
> FATAL: failed to initialize timezone_abbreviations to "Default"
> LOG: background writer process (PID 1568) exited with exit code 0
> LOG: terminating any other active server processes
> FATAL: failed to initialize timezone_abbreviations to "Default"
> LOG: all server processes terminated; reinitializing
> FATAL: failed to initialize timezone_abbreviations to "Default"
> FATAL: failed to initialize timezone_abbreviations to "Default"
> LOG: background writer process (PID 244) exited with exit code 0
> LOG: terminating any other active server processes
> LOG: all server processes terminated; reinitializing
> FATAL: failed to initialize timezone_abbreviations to "Default"
> FATAL: failed to initialize timezone_abbreviations to "Default"
> LOG: background writer process (PID 468) exited with exit code 0
> LOG: terminating any other active server processes
>
> ...
>
>
> Stefan
>
>


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

I wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> The TimeZone changes are looking might suspicious ...

> FATAL: failed to initialize timezone_abbreviations to "Default"

> Hm. It looks like this is working in the postmaster but failing
> in subprocesses. I'll see if I can duplicate it using EXEC_BACKEND.

Nope, works fine with EXEC_BACKEND, so it's something Windows-specific.
I'm not sure why you're not getting any more specific messages ---
they should be coming out at WARNING level AFAICS. You'll need to trace
through load_tzoffsets() and see why it's failing in the subprocess.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Andrew Dunstan <andrew@dunslane.net> writes:
> The TimeZone changes are looking might suspicious ...

>> FATAL: failed to initialize timezone_abbreviations to "Default"

Hm. It looks like this is working in the postmaster but failing
in subprocesses. I'll see if I can duplicate it using EXEC_BACKEND.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane wrote:
> I wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>> The TimeZone changes are looking might suspicious ...
>
>> FATAL: failed to initialize timezone_abbreviations to "Default"
>
>> Hm. It looks like this is working in the postmaster but failing
>> in subprocesses. I'll see if I can duplicate it using EXEC_BACKEND.
>
> Nope, works fine with EXEC_BACKEND, so it's something Windows-specific.
> I'm not sure why you're not getting any more specific messages ---
> they should be coming out at WARNING level AFAICS. You'll need to trace
> through load_tzoffsets() and see why it's failing in the subprocess.

that was a bit painful but we failed to see a useful error message due
to the fact that we have been activly suppressing it - with a quick hack
like:

---
/home/pgbuild/pgfarmbuild/HEAD/pgsql/src/backend/utils/misc/tzparser.c
Tue Jul 25 05:51:21 2006
+++ src/backend/utils/misc/tzparser.c Fri Jul 28 19:33:24 2006
@@ -326,7 +326,6 @@
if (!tzFile)
{
/* at level 0, if file doesn't exist, guc.c's complaint
is enough */
- if (errno != ENOENT || depth > 0)
ereport(tz_elevel,
(errcode_for_file_access(),
errmsg("could not read time
zone file \"%s\": %m",


(will probably get mangled by my mailer)


I get a much more useful:

WARNING: could not read time zone file "Default": No such file or directory
FATAL: failed to initialize timezone_abbreviations to "Default"
WARNING: could not read time zone file "Default": No such file or directory
FATAL: failed to initialize timezone_abbreviations to "Default"
LOG: background writer process (PID 3776) exited with exit code 0
LOG: terminating any other active server processes
WARNING: could not read time zone file "Default": No such file or directory
FATAL: failed to initialize timezone_abbreviations to "Default"
LOG: all server processes terminated; reinitializing
WARNING: could not read time zone file "Default": No such file or directory

which gives a strong further hint at the underlying issue.


Stefan

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> I get a much more useful:

> WARNING: could not read time zone file "Default": No such file or directory
> FATAL: failed to initialize timezone_abbreviations to "Default"

Hm, but why would the file not be there? Try hacking it to print the
whole path it's trying to open, maybe that will help.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> I get a much more useful:
>
>> WARNING: could not read time zone file "Default": No such file or directory
>> FATAL: failed to initialize timezone_abbreviations to "Default"
>
> Hm, but why would the file not be there? Try hacking it to print the
> whole path it's trying to open, maybe that will help.

WARNING: could not read time zone file
"/home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default": No
such file or directory
FATAL: failed to initialize timezone_abbreviations to "Default"
WARNING: could not read time zone file
"/home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default": No
such file or directory
FATAL: failed to initialize timezone_abbreviations to "Default"
LOG: background writer process (PID 1460) exited with exit code 0
LOG: terminating any other active server processes
WARNING: could not read time zone file
"/home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default": No
such file or directory

$ ls -l /home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default
-rw-r--r-- 1 pgbuild Administ 28630 Jul 28 20:03
/home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default

so it's there but as a msys-virtual path - is that get passed to some
win32 function expecting a windows-style path ?



Stefan

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> WARNING: could not read time zone file
> "/home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default": No
> such file or directory

> $ ls -l /home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default
> -rw-r--r-- 1 pgbuild Administ 28630 Jul 28 20:03
> /home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default

> so it's there but as a msys-virtual path - is that get passed to some
> win32 function expecting a windows-style path ?

Hm. We pass it to fopen(). The equivalent code in pgtz.c generates the
path to /timezone files exactly the same way, but uses open() ... is
there a difference in what they'll take?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Stefan Kaltenbrunner wrote:
> WARNING: could not read time zone file
> "/home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default": No
> such file or directory
>

This is an MSys virtual path, of which postgres naturally knows
nothing.We should have made the appropriate calls to turn it into a
genuine Windows path. (Darn, not having a Windows box to test on is
annoying).

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org