Re: [HACKERS] Buildfarm issues on specific machines

On Sun, 17 Jul 2005, Tom Lane wrote: The short answer is that you should install flex 2.5.4, or else forget about testing the 7.2 branch. I don't think anyone will be very interested in making 7.2 work with flex 2.5.31. Actually there are problems in the 7.3 branch as well in the cube,

[HACKERS] Buildfarm

Since tom seems to be fixing the back branches, I added 7.3 and 7.2 to firefly's set of branches it tries. Unfortunately neither one went green :(. Also, 7.4 seems to now need some contrib check hacking. (It got further, but not green yet). Just FYI. LER -- Larry Rosenman

Re: [HACKERS] Segfault Exiting psql

On Jul 15, 2005, at 4:55 PM, Tom Lane wrote: This noise wasn't there ever before; I do not know if it's just that Apple's tools got pickier recently, or if we've broken something. I think they're new to Tiger, because I saw some warnings I ignored when I built Pg. Second, at exit from an

Re: [HACKERS] Buildfarm issues on specific machines

First off, thanks for looking into this, Tom, and thanks to Andrew for all the stellar work on the buildfarm, I'm glad to be a part of it. Perhaps this will help in the diagnosis of why REL7_2_STABLE fails on arbor (aka caribou). Please let me know if there is anything I can try on this side, or

Re: [HACKERS] Changes improve the performance of INSERT and UPDATE

Tom Lane wrote: Hiroki Kataoka [EMAIL PROTECTED] writes: This small patch improves the performance of INSERT and UPDATE. By my machine, these changes raised the performance about 5%~10% in pgbench. Wouldn't it be a lot less invasive to search down from the end, instead of changing the page

[HACKERS] Changes improve the performance of INSERT and UPDATE

Hi all, This small patch improves the performance of INSERT and UPDATE. By my machine, these changes raised the performance about 5%~10% in pgbench. Please take a benchmark in a reliable environment. Since I may forget some required changes, I specify that this patch is experimental. But

Re: [HACKERS] Changes improve the performance of INSERT and UPDATE

Tom Lane wrote: This small patch improves the performance of INSERT and UPDATE. By my machine, these changes raised the performance about 5%~10% in pgbench. BTW, in profiling the backend I've never seen PageAddItem take more than about 1% of the runtime, and in pgbench in particular it seems

Re: [HACKERS] Buildfarm issues on specific machines

Tom, thanks for this. I regularly send out private emails about what appear to be local issues. Tom Lane wrote: I spent a little time today cleaning up easily-fixed problems that are causing buildfarm failures in various back branches. Hopefully that will result in a few more green

Re: [HACKERS] Buildfarm issues on specific machines

Kris Jurka [EMAIL PROTECTED] writes: On Sun, 17 Jul 2005, Tom Lane wrote: The short answer is that you should install flex 2.5.4, or else forget about testing the 7.2 branch. I don't think anyone will be very interested in making 7.2 work with flex 2.5.31. Actually there are problems in the

Re: [HACKERS] Buildfarm

Larry Rosenman ler@lerctr.org writes: Since tom seems to be fixing the back branches, I added 7.3 and 7.2 to firefly's set of branches it tries. Unfortunately neither one went green :(. There's a limit to how much time I'm prepared to put into that endeavor ;-) and one Saturday afternoon is

Re: [HACKERS] Buildfarm issues on specific machines

Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: potoroo [HEAD, 7.4]: lock file /tmp/.s.PGSQL.65432.lock already exists I'm not sure if this is a problem with a stale lock file left around from an old run, or if it happens because the machine is configured to try to build/test

Re: [HACKERS] Buildfarm

Tom Lane wrote: Larry Rosenman ler@lerctr.org writes: Since tom seems to be fixing the back branches, I added 7.3 and 7.2 to firefly's set of branches it tries. Unfortunately neither one went green :(. There's a limit to how much time I'm prepared to put into that endeavor ;-) and

Re: [HACKERS] Buildfarm issues on specific machines

Tom Lane wrote: I believe that if we do something like TEMP_PORT = 5$(default_port) check: pg_regress ... --temp_port=$(TEMP_PORT) then the port could be overridden without any source code hacks by gmake TEMP_PORT=nnn check. Works for me. Let's do it. If I understand this

Re: [HACKERS] Buildfarm issues on specific machines

Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I believe that if we do something like TEMP_PORT = 5$(default_port) check: pg_regress ... --temp_port=$(TEMP_PORT) then the port could be overridden without any source code hacks by gmake TEMP_PORT=nnn check. Works for me.

[HACKERS] Minor buildfarm HOWTO comment

BTW, I noticed that the buildfarm HOWTO says ... Finally, I set up a cron job on the mirror machine to update the mirror every 15 minutes - this should not be too big a deal, as CVSup is extremely efficient, and even doing this so frequently should not incur a lot of bandwidth use. AFAIK the

Re: [HACKERS] Buildfarm issues on specific machines

Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I believe that if we do something like TEMP_PORT = 5$(default_port) check: pg_regress ... --temp_port=$(TEMP_PORT) then the port could be overridden without any source code hacks by gmake TEMP_PORT=nnn

Re: [HACKERS] Minor buildfarm HOWTO comment

Tom Lane wrote: BTW, I noticed that the buildfarm HOWTO says ... Finally, I set up a cron job on the mirror machine to update the mirror every 15 minutes - this should not be too big a deal, as CVSup is extremely efficient, and even doing this so frequently should not incur a lot of

[HACKERS] The reason for loris' intermittent prepared_xacts failures

I have what seems a pretty solid theory about the intermittent check failures on buildfarm member loris. Every non-Windows platform executes the parallel regression tests using C locale ... but not Windows, because of this hack in pg_regress.sh: unset LC_COLLATE LC_CTYPE LC_MONETARY LC_MESSAGES

Re: [HACKERS] Minor buildfarm HOWTO comment

On 7/18/05 5:13 AM, Andrew Dunstan [EMAIL PROTECTED] wrote: I was told, quite possibly incorrectly, and I forget by whom, that the 1 hour delay didn't apply to CVSup. I think that might have been me -- if you're syncing from mcvsup.postgresql.org, there should be no delay. -Neil

Re: [HACKERS] Order by optimisations?

Does it know that the input to the sort routine is already sorted and hence is a no-op? Yes No, but in most cases this will use an index and hence will assume that the index is responsible for ordering. regards, tom lane ---(end of

Re: [HACKERS] Minor buildfarm HOWTO comment

Neil Conway wrote: On 7/18/05 5:13 AM, Andrew Dunstan [EMAIL PROTECTED] wrote: I was told, quite possibly incorrectly, and I forget by whom, that the 1 hour delay didn't apply to CVSup. I think that might have been me -- if you're syncing from mcvsup.postgresql.org, there should be

Re: [HACKERS] The reason for loris' intermittent prepared_xacts failures

Tom Lane wrote: 4. Fix the Windows special case so that we test in C locale not en_US locale (is this even possible on that platform?) Should we be using --no-locale in pg_regress ... or wouldn't that help? --no-locale does work on Windows - I recently added it to the buildfarm

[HACKERS] Missing info for buildfarm reports

I'm finding it a bit annoying that the buildfarm results pages will only show me what the program thinks I need to know. For example, to debug the current 7.4-branch dblink failures, it'd be awfully useful to compare the build logs of those systems to the same machines' logs for the not-broken

[HACKERS] Buildfarm failure analysis: penguin on 7.4 branch

Buildfarm member penguin has never got past this point in half a year of trying: creating template1 database in /home/postgres/pgfarmbuild/REL7_4_STABLE/pgsql.7701/src/test/regress/./tmp_check/data/base/1... ok initializing pg_shadow... TRAP: