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:
FailedAssertion("!(StrategyEvaluationIsValid(evaluat
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 8.0
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
script
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
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 broadcast
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
--
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 L
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 bandw
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 che
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
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
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 r
Tom Lane wrote:
"Larry Rosenman" 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
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 bu
"Larry Rosenman" 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 about it.
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 proble
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" entri
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 t
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
n
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 changin
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 i
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
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
23 matches
Mail list logo
