Quoth [EMAIL PROTECTED] (Peter Eisentraut):
> Andrew Dunstan wrote:
>> Lately there have been some buildfarm registrations for "Debian
>> testing/unstable" or similarly described machines. I have kicked back
>> against these, as the description seems to me to be far too open
>> ended.
>
> Then again, it would be useful to actually test on Debian
> testing/unstable (or pre-release branches of other OS), because that
> would (a) expose problems with new toolchains and such earlier than
> in released versions, and (b) provide advance testing for when
> testing becomes the release. Consider, the number of users that
> will run 8.2 on Debian stable is probably going to be less than the
> number of users who will run 8.2 on what today is testing.
I suppose I'm partly to blame for bringing this one up; I proposed
doing a build on a box at home and at work (one IA-32, one AMD-64),
both running something of a mix of Debian unstable/testing.
> I agree that the lack of a fixed version designation is unsatisfactory.
> I'm not sure whether that is actually necessary, though. If PostgreSQL
> doesn't work on some machine, then that's a problem anyway.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yeah. There are a somewhat limited number of sorts of problems that
could cause this:
- I could be running an icky, out of date set of libraries or such.
In which case there's not much value in trying to fix things on the
PostgreSQL side.
- A change perhaps forthcoming in some future Debian release has
busted something.
Knowing that sooner is better than knowing that later...
- Such a problem may be ephermal; it may be something I need to report
to someone _else_ upstream.
For instance, a bleeding-edge readline may have just "drawn blood,"
and I need to let them know...
It seems to me that there is some value in putting together a script
that tries to identify some of the interesting bits of the toolchain.
Here's a "Mark 0" version:
================================================
#!/bin/sh
FINDGCCVERSION=`$CC --version`
KERNELVERSION=`uname -a`
ARCH=`arch`
# Uncomment one of the following...
#DEBIAN
#LIBC=`dpkg -l libc6`
#REDHAT/SuSE/Fedora
#LIBC=`rpm -q libc6`
#Slackware, etc
#LIBC=`ls -l /lib/libc.so.*`
================================================
I'll bet one could get more information pretty cheaply, including
release names, and such, by recognizing the existence of
distribution-specific files in /etc, such as /etc/debian_release,
/etc/SuSE-release, /etc/fedora-release, /etc/redhat-release....
It's not necessarily vital to recognize every combination of anything
that's plausible; if someone has an oddball system, reporting the
details are their problem...
--
output = ("cbbrowne" "@" "linuxfinances.info")
http://linuxdatabases.info/info/x.html
"Natives who beat drums to drive off evil spirits are objects of scorn
to smart Americans who blow horns to break up traffic jams."
-- Unknown
---------------------------(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
