Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
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-committers/2006-07/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 ... Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
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-committers/2006-07/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
Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
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-committers/2006-07/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
Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
I wrote: Andrew Dunstan [EMAIL PROTECTED] 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
Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
Andrew Dunstan [EMAIL PROTECTED] 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
Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
Tom Lane wrote:
I wrote:
Andrew Dunstan [EMAIL PROTECTED] 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
Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
Stefan Kaltenbrunner [EMAIL PROTECTED] 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
Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] 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 Administ28630 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
Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
Stefan Kaltenbrunner [EMAIL PROTECTED] 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 Administ28630 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
Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
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
Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: WARNING: could not read time zone file /home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default: No such file or directory so it's there but as a msys-virtual path - is that get passed to some win32 function expecting a windows-style path ? Doh, I see what's the problem: we calculate the sharedir path using my_exec_path, and falling back to the hardwired PGSHAREDIR path if my_exec_path isn't correct. The problem is that in a Windows subprocess, my_exec_path isn't correct until read_backend_variables has been done, and *that happens after InitializeGUCOptions* in SubPostmasterMain(). So we're trying to set up the tz name data before we have the path we need. The reason I didn't notice this in testing with EXEC_BACKEND is that I wasn't testing in a relocated installation, and so the fallback get_share_path calculation got the right answer anyway. Not sure about a clean fix. Probably we'll have to do something similar to the way TimeZone is handled, where we don't try to read in the data until later on in the initialization sequence. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: WARNING: could not read time zone file /home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default: No such file or directory so it's there but as a msys-virtual path - is that get passed to some win32 function expecting a windows-style path ? Doh, I see what's the problem: we calculate the sharedir path using my_exec_path, and falling back to the hardwired PGSHAREDIR path if my_exec_path isn't correct. The problem is that in a Windows subprocess, my_exec_path isn't correct until read_backend_variables has been done, and *that happens after InitializeGUCOptions* in SubPostmasterMain(). So we're trying to set up the tz name data before we have the path we need. Is there a reason we have to do things in this order? Could we just postpone the call to InitializeGUCOptions() for a couple of lines? If not, then ... The reason I didn't notice this in testing with EXEC_BACKEND is that I wasn't testing in a relocated installation, and so the fallback get_share_path calculation got the right answer anyway. Not sure about a clean fix. Probably we'll have to do something similar to the way TimeZone is handled, where we don't try to read in the data until later on in the initialization sequence. I guess we'd need to set a flag that would postpone reading the data just during the startup phase, but have it called immediately in all other cases. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
Andrew Dunstan [EMAIL PROTECTED] writes: Is there a reason we have to do things in this order? Could we just postpone the call to InitializeGUCOptions() for a couple of lines? Maybe, but I'm disinclined to mess with that. I have a patch that makes it work like TimeZone, but am having difficulty committing ... looks like that Polish script kiddie is at it again ... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
