[BUGS] horology regression test failure

#1

--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

On almost all Debian platforms the horology test for 8.0.3 fails.
Sometimes it works on a platform, sometimes not, I did not yet find a
pattern, but most often it fails with something like

*** ./expected/horology.out Sun Jul 11 04:57:20 2004
--- ./results/horology.out Thu Sep 29 20:48:57 2005
***************
*** 1775,1784 ****

Quote:

Quote:

--- 1775,1784 ----

Quote:

Quote:

However, not even that is entirely consistent; the numbers are always
fine, but the second timezone is sometimes PST, sometimes PDT. Is this
problem known?

In case it matters, packages are configured with

--enable-nls \
--enable-integer-datetimes \
--enable-debug \
--disable-rpath \
--with-tcl \
--with-perl \
--with-python \
--with-pam \
--with-krb5 \
--with-openssl \
--with-gnu-ld \
--with-tclconfig=3D/usr/lib/tcl$(TCL_VER) \
--with-tkconfig=3D/usr/lib/tk$(TCL_VER) \
--with-includes=3D/usr/include/tcl$(TCL_VER):/usr/lib/R=
/include \
--with-pgport=3D5432 \

Thanks in advance!

Martin
--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

--FCuugMFkClbJLl1L
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDPFfGDecnbV4Fd/IRAu1QAJ0a3pjSRMzuEr6TDbaVuDkfhAE8rACeKvu3
JWV6RnKRZaVydprzdIlWCNQ=
=7FmT
-----END PGP SIGNATURE-----

--FCuugMFkClbJLl1L--

#2

On Thu, Sep 29, 2005 at 11:08:22PM +0200, Martin Pitt wrote:

Quote:

On almost all Debian platforms the horology test for 8.0.3 fails.
Sometimes it works on a platform, sometimes not, I did not yet find a
pattern, but most often it fails with something like

I think this test is supposed to fail when it's run near a DST
transition. The question to be asking is, then, is the server running
with a timezone that has just changed DST or is about to change? In
this case, ignore the report.

Note in the diff below that the originals have PDT (second column)/PDT
(fourth column) while the result obtained from the test is PDT/PST; or
PST/PDT and PST/PST; or PST/PST and PST/PDT.

Does this explain the issue?

Quote:

--
Alvaro Herrera http://www.PlanetPostgreSQL.org
"Porque Kim no hacia nada, pero, eso sí,
con extraordinario éxito" ("Kim", Kipling)

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

#3

Martin Pitt <martin (AT) piware (DOT) de> writes:

Quote:

On almost all Debian platforms the horology test for 8.0.3 fails.

Before PG 8.0, I'd have said you were running with a timezone library
that didn't understand about DST before 1970. It shouldn't be happening
in 8.0 though.

regards, tom lane

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

#4

Hi Tom!

Tom Lane [2005-09-29 17:50 -0400]:

Quote:

Martin Pitt <martin (AT) piware (DOT) de> writes:
On almost all Debian platforms the horology test for 8.0.3 fails.

Before PG 8.0, I'd have said you were running with a timezone library
that didn't understand about DST before 1970. It shouldn't be happening
in 8.0 though.

The underlying glibc is the same everywhere: Debian's 2.3.5 on all
platforms and in all cases I tried it. And, for the record, the same
problem happens with 8.1 beta 3.

Thanks,

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

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

#5

--HjGz34yYE1BNnn/x
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi again!

Martin Pitt [2005-09-29 23:08 +0200]:

Quote:

Hi!
=20
On almost all Debian platforms the horology test for 8.0.3 fails.
Sometimes it works on a platform, sometimes not, I did not yet find a
pattern, but most often it fails with something like
[...]

I now think I know what is wrong here.

This test has usually succeeded on my own computer, but it always
fails on the Debian buildds (which build packages in a minimal
chroot). As soon as I move away /usr/share/postgresql/8.1/timezone
when building 8.1, the horology test fails. I. e. as long as the
package that I currently build is already installed, then it works,
but it fails if the package is not yet installed.

The log entry seems to confirm this. I always get

LOG: could not open directory "/usr/share/postgresql/8.0/timezone": No suc=
h file or directory

when running the 8.0 test suite on the debian buildds during package
build.

So it seems that the test suite uses the timezone files from the
installed system instead of the files in the temporary installation in
the regression test directory. Is there an easy way to fix that?

Thanks!

Martin

--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

--HjGz34yYE1BNnn/x
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDqD8bDecnbV4Fd/IRAug0AJ9kSyRLR8AfGb8safMBwVx+ZevhzwCfYHhR
LjKBR0gs9CSa+pzcXXf1ZSc=
=AYBL
-----END PGP SIGNATURE-----

--HjGz34yYE1BNnn/x--

#6

Martin Pitt <martin (AT) piware (DOT) de> writes:

Quote:

So it seems that the test suite uses the timezone files from the
installed system instead of the files in the temporary installation in
the regression test directory.

It's not supposed to, and AFAICT it works fine for me (not only on my
personal machines, but also on Red Hat's build machines). Perhaps
you've done something to break the package-relocation logic? All those
files should be sought via paths relative to the postmaster executable.

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

#7

--jWL1oGPK2mPq0rME
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Tom!

Tom Lane [2005-12-20 12:49 -0500]:

Quote:

Martin Pitt <martin (AT) piware (DOT) de> writes:
So it seems that the test suite uses the timezone files from the
installed system instead of the files in the temporary installation in
the regression test directory.
=20
It's not supposed to, and AFAICT it works fine for me (not only on my
personal machines, but also on Red Hat's build machines). Perhaps
you've done something to break the package-relocation logic? All those
files should be sought via paths relative to the postmaster executable.

Maybe I did something wrong with the configure options. That bug is
reproducible with the pristine upstream 8.1.1 tarball and doing:

=2E/configure --prefix=3D/usr --mandir=3D"\${prefix}/share/man" \
--sysconfdir=3D/etc --libdir=3D"\${prefix}/lib/postgresql/8.1/lib" \
--libexecdir=3D"\${prefix}/lib/postgresql-8.1/lib" \
--mandir=3D\${prefix}/share/postgresql/8.1/man \
--with-docdir=3D\${prefix}/share/doc/postgresql-doc-8.1 \
--datadir=3D\${prefix}/share/postgresql/8.1 \
--bindir=3D\${prefix}/lib/postgresql/8.1/bin \
--includedir=3D\${prefix}/include/postgresql/8.1
make
make check

However, it does *not* happen when I do not specify any configure
options at all. I'll try to narrow down the problematic change
further, but can you already see what the problem is here?

Thanks,

Martin

--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

--jWL1oGPK2mPq0rME
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDqGgtDecnbV4Fd/IRArbtAKDEd/MYs6xsCZia3w+EA6fOk7bUSQCfYJ06
BJuF8V6VHqJK9FsUyXFnOyY=
=mZHn
-----END PGP SIGNATURE-----

--jWL1oGPK2mPq0rME--

#8

--uN3tURjgVTLfI0kr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

Martin Pitt [2005-12-20 21:23 +0100]:

Quote:

Maybe I did something wrong with the configure options. That bug is
reproducible with the pristine upstream 8.1.1 tarball and doing:
=20
./configure --prefix=3D/usr --mandir=3D"\${prefix}/share/man" \
--sysconfdir=3D/etc --libdir=3D"\${prefix}/lib/postgresql/8.1/lib" \
--libexecdir=3D"\${prefix}/lib/postgresql-8.1/lib" \
--mandir=3D\${prefix}/share/postgresql/8.1/man \
--with-docdir=3D\${prefix}/share/doc/postgresql-doc-8.1 \
--datadir=3D\${prefix}/share/postgresql/8.1 \
--bindir=3D\${prefix}/lib/postgresql/8.1/bin \
--includedir=3D\${prefix}/include/postgresql/8.1

A mere

./configure --libdir=3D/usr/lib/postgresql/8.1/lib --bindir=3D/usr/lib/pos=
tgresql/8.1/bin

is enough to reproduce the problem. With only --libdir, it works, and
with only --bindir the test suite does not run at all because the
postmaster cannot find $libdir (but that is still justifiable).

Thanks,

Martin

--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

--uN3tURjgVTLfI0kr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDqHiqDecnbV4Fd/IRArkuAJ9gDq9p16KH2VmSFb++YDyzoFBaIQCfY6/y
TmffkxrAaf+MhxAtWLtrKQ4=
=Qqf0
-----END PGP SIGNATURE-----

--uN3tURjgVTLfI0kr--

#9

Martin Pitt <martin (AT) piware (DOT) de> writes:

Quote:

Maybe I did something wrong with the configure options. That bug is
reproducible with the pristine upstream 8.1.1 tarball and doing:

=2E/configure --prefix=/usr --mandir="\${prefix}/share/man" \
--sysconfdir=/etc --libdir="\${prefix}/lib/postgresql/8.1/lib" \
--libexecdir="\${prefix}/lib/postgresql-8.1/lib" \
--mandir=\${prefix}/share/postgresql/8.1/man \
--with-docdir=\${prefix}/share/doc/postgresql-doc-8.1 \
--datadir=\${prefix}/share/postgresql/8.1 \
--bindir=\${prefix}/lib/postgresql/8.1/bin \
--includedir=\${prefix}/include/postgresql/8.1

However, it does *not* happen when I do not specify any configure
options at all. I'll try to narrow down the problematic change
further, but can you already see what the problem is here?

Yeah, the chosen-at-random pathnames ;-). I quote from the comments
for make_relative_path():

* This function exists to support relocation of installation trees.
*
* ret_path is the output area (must be of size MAXPGPATH)
* target_path is the compiled-in path to the directory we want to find
* bin_path is the compiled-in path to the directory of executables
* my_exec_path is the actual location of my executable
*
* If target_path matches bin_path up to the last directory component of
* bin_path, then we build the result as my_exec_path (less the executable
* name and last directory) joined to the non-matching part of target_path.
* Otherwise, we return target_path as-is.
*
* For example:
* target_path = '/usr/local/share/postgresql'
* bin_path = '/usr/local/bin'
* my_exec_path = '/opt/pgsql/bin/postmaster'
* Given these inputs we would return '/opt/pgsql/share/postgresql'

In short, you can set --prefix however you want, but you really can't
tack random decoration between --prefix and /bin, /share and friends;
else make_relative_path will be unable to figure out how to transform
one to the other.

We could doubtless improve make_relative_path to some extent, but the
mess you have above seems impossible to deal with. How is a mere
program supposed to deduce where things were moved to, given only
knowledge of the actual location of --bindir? I see little if any
pattern that would allow prediction of the corresponding --datadir,
let alone --libexecdir or --includedir ...

regards, tom lane

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

#10

Martin Pitt <martin (AT) piware (DOT) de> writes:

Quote:

./configure --libdir=3D/usr/lib/postgresql/8.1/lib --bindir=3D/usr/lib/pos=
tgresql/8.1/bin

is enough to reproduce the problem. With only --libdir, it works, and
with only --bindir the test suite does not run at all because the
postmaster cannot find $libdir (but that is still justifiable).

Try adding --datadir=/usr/lib/postgresql/8.1/share to that. Actually,
you'd be best off replacing all three options with
--prefix=/usr/lib/postgresql/8.1
because that will make sure that the entire installation is consistent.

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