SEO

#1 (**permalink**) 04-12-2008, 07:24 AM

I see that kudu and dragonfly are now failing regression in the 7.3 and
7.4 branches, as a consequence of this patch:
http://archives.postgresql.org/pgsql...2/msg00491.php

Is it reasonable to assume that that machine will soon be patched to
know about the new US DST rules? If not, I suppose we could install
variant horology-solaris-1947_1.out files to allow either result to
succeed, but it seems a bit silly ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

#2 (**permalink**) 04-12-2008, 07:24 AM

Tom Lane wrote:
> I see that kudu and dragonfly are now failing regression in the 7.3 and
> 7.4 branches, as a consequence of this patch:
> http://archives.postgresql.org/pgsql...2/msg00491.php
>
> Is it reasonable to assume that that machine will soon be patched to
> know about the new US DST rules? If not, I suppose we could install
> variant horology-solaris-1947_1.out files to allow either result to
> succeed, but it seems a bit silly ...
>
>

Yeah. I have stopped building 7.4 on hyena.

cheers

andrew

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

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

#3 (**permalink**) 04-12-2008, 07:24 AM

On Tue, 27 Feb 2007, Tom Lane wrote:

> I see that kudu and dragonfly are now failing regression in the 7.3 and
> 7.4 branches, as a consequence of this patch:
> http://archives.postgresql.org/pgsql...2/msg00491.php
>
> Is it reasonable to assume that that machine will soon be patched to
> know about the new US DST rules? If not, I suppose we could install
> variant horology-solaris-1947_1.out files to allow either result to
> succeed, but it seems a bit silly ...
>

I'll look at an upgrade. Eel is failing as well, but surprisingly canary
is not. Canary hasn't had any updates applied, so why isn't it failing as
well:

jurka@netbsd:~$ zdump -v /etc/localtime | grep 2007
/etc/localtime Sun Apr 1 08:59:59 2007 UTC = Sun Apr 1 01:59:59 2007
MST isdst=0
/etc/localtime Sun Apr 1 09:00:00 2007 UTC = Sun Apr 1 03:00:00 2007
MDT isdst=1
/etc/localtime Sun Oct 28 07:59:59 2007 UTC = Sun Oct 28 01:59:59 2007
MDT isdst=1
/etc/localtime Sun Oct 28 08:00:00 2007 UTC = Sun Oct 28 01:00:00 2007
MST isdst=0

Kris Jurka

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

#4 (**permalink**) 04-12-2008, 07:24 AM

On Tue, 27 Feb 2007, Kris Jurka wrote:

> I'll look at an upgrade. Eel is failing as well, but surprisingly canary is
> not. Canary hasn't had any updates applied, so why isn't it failing as well:
>

Shouldn't all of the buildfarm members be failing either before or after
the patch? That doesn't seem to be the case for any of them.

Kris Jurka

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

#5 (**permalink**) 04-12-2008, 07:24 AM

Kris Jurka <books@ejurka.com> writes:
> Shouldn't all of the buildfarm members be failing either before or after
> the patch? That doesn't seem to be the case for any of them.

No, because for the "standard" regression behavior we have variant
result files both with and without the DST law change: see horology and
horology_1. The issue only comes up for machines that were matching to
horology-no-DST-before-1970.out (which may be only old HPUX) or
horology-solaris-1947.out (which I suppose is only Solaris). The reason
I got around to making the patch now is I recently updated my old HPUX
machine for the law change, and so 7.x started to fail for me ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

#6 (**permalink**) 04-12-2008, 07:24 AM

On Tue, 27 Feb 2007, Tom Lane wrote:

> No, because for the "standard" regression behavior we have variant
> result files both with and without the DST law change: see horology and
> horology_1. The issue only comes up for machines that were matching to
> horology-no-DST-before-1970.out (which may be only old HPUX) or
> horology-solaris-1947.out (which I suppose is only Solaris). The reason
> I got around to making the patch now is I recently updated my old HPUX
> machine for the law change, and so 7.x started to fail for me ...
>

OK, kudu + dragonfly updated. I probably won't get around to fixing eel
(cygwin) for some time though.

Kris Jurka

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

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

7.x horology regression test on Solaris buildfarm machines