Re: [HACKERS] Feature Request
On 20/2/06 1:26 pm, Peter Eisentraut [EMAIL PROTECTED] wrote: Am Montag, 20. Februar 2006 14:15 schrieb Q Beukes: Hey, This might not be much, but can there maybe be a future feature for having a shortcut to set search_path='schema-name'; similiar to \c dbname ?? pei=# \set X 'set search_path = ' pei=# :X public; SET pei=# show search_path; search_path - public That seems quite handy to know! can these be saved anywhere such that I don't have to run the \set ... command every session? Thanks Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Feature Request
ALTER USER bob SET search_path ...? Sorry I didn't mean the search_path example, but I was thinking I could setup a short cut for a common query, eg: \set logins SQL query :logins Could save this such that the short cut is available every time I open psql? Thanks Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] 8.1RC1 fails opr_sanity on osx
Just the one fail on OSX 10.3.9 opr_sanity ... FAILED Is this a known problem, or something specific to my machine... I can post regression.diffs (quite long) if required ... Thanks Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.1RC1 fails opr_sanity on osx
On 31/10/05 1:32 pm, Bruce Momjian pgman@candle.pha.pa.us wrote: Adam Witney wrote: Just the one fail on OSX 10.3.9 opr_sanity ... FAILED Is this a known problem, or something specific to my machine... I can post regression.diffs (quite long) if required ... Uh, regression.diffs is large? MY guess is your backend crashed, for some unknown reason, so all the queries after the crash just failed. I can't think of another reason for that diff file to be large. Is the failure repoducable? Seems a bit random actually... Here are the results of 3 successive make check's, the fourth passed all tests! http://bugs.sgul.ac.uk/downloads/temp/regression1.diffs http://bugs.sgul.ac.uk/downloads/temp/regression2.diffs http://bugs.sgul.ac.uk/downloads/temp/regression3.diffs -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.1RC1 fails opr_sanity on osx
On 31/10/05 2:13 pm, Bruce Momjian pgman@candle.pha.pa.us wrote: Adam Witney wrote: On 31/10/05 1:32 pm, Bruce Momjian pgman@candle.pha.pa.us wrote: Adam Witney wrote: Just the one fail on OSX 10.3.9 opr_sanity ... FAILED Is this a known problem, or something specific to my machine... I can post regression.diffs (quite long) if required ... Uh, regression.diffs is large? MY guess is your backend crashed, for some unknown reason, so all the queries after the crash just failed. I can't think of another reason for that diff file to be large. Is the failure repoducable? Seems a bit random actually... Here are the results of 3 successive make check's, the fourth passed all tests! http://bugs.sgul.ac.uk/downloads/temp/regression1.diffs http://bugs.sgul.ac.uk/downloads/temp/regression2.diffs http://bugs.sgul.ac.uk/downloads/temp/regression3.diffs Yea, that helps. The errors you have are really these: ! psql: could not fork new process for connection: Resource temporarily unavailable and ! psql: could not send startup packet: Broken pipe Is anything else big running on your machine? I looked at the OSX configuration section here: http://candle.pha.pa.us/main/writings/pgsql/sgml/kernel-resources.html but didn't see anything significant. My guess is that the parallel nature of the regression tests are exhausting some system resource on your machine. Does the kernel log have anything of interest? Ah that probably explains it... It is my laptop and I have quite a few things running... So should probably run the make check when I first start it up maybe. Thanks for the help Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] problem installing 8.0.0beta5 on OS X 10.3
You shouldn't need to edit configure. I compiled 8.0b5 on 10.3.6 with no
problems yesterday
I am no expert, but this error seems to have come up on other platforms...
Here was the response in the mailing lists before
http://archives.postgresql.org/pgsql-ports/2004-07/msg1.php
You may also want to report back to the list what your gcc version is?
Also, if you installed readline with fink you may need to configure like so:
./configure --with-libs=/sw/lib --with-includes=/sw/include
(if your fink is installing in /sw of course)
HTH
Adam
I'm trying to compile beta5 on osx 10.3.6
without success, I have XCode 1.5 installed.
Could you please give me instructions?
I have readline installed from fink.
Bison is there from Apple.
This is from the Terminal.app:
~/Desktop/postgresql-8.0.0beta5 (alpha) ./configure
--bindir=/usr/local/bin --mandir=/usr/local/share/man/ --enable-recode
--enable-syslog --enable-unicode-conversion --enable-multibyte
--with-includes=/sw/include/ --with-libraries=/sw/lib
checking build system type... powerpc-apple-darwin7.6.0
checking host system type... powerpc-apple-darwin7.6.0
checking which template to use... darwin
checking whether to build with 64-bit integer date/time support... no
checking whether NLS is wanted... no
checking for default port number... 5432
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
After removing line 2050 to 2077 in configure:
#
# Check the compiler produces executables we can run. If not, either
# the compiler is broken, or we cross compile.
echo $as_me:$LINENO: checking whether the C compiler works 5
echo $ECHO_N checking whether the C compiler works... $ECHO_C 6
# FIXME: These cross compiler hacks should be removed for Autoconf 3.0
# If not cross compiling, check that we can run a simple program.
if test $cross_compiling != yes; then
if { ac_try='./$ac_file'
{ (eval echo $as_me:$LINENO: \$ac_try\) 5
(eval $ac_try) 25
ac_status=$?
echo $as_me:$LINENO: \$? = $ac_status 5
(exit $ac_status); }; }; then
cross_compiling=no
else
if test $cross_compiling = maybe; then
cross_compiling=yes
else
{ { echo $as_me:$LINENO: error: cannot run C compiled programs.
If you meant to cross compile, use \`--host'. 5
echo $as_me: error: cannot run C compiled programs.
If you meant to cross compile, use \`--host'. 2;}
{ (exit 1); exit 1; }; }
fi
fi
fi
echo $as_me:$LINENO: result: yes 5
echo ${ECHO_T}yes 6
#
I was able to configure, at least I got:
All of PostgreSQL successfully made. Ready to install.
but then:
~/Desktop/postgresql-8.0.0beta5 (user) sudo make install
make -C doc install
for file in man1/*.1 man7/*.7 ; do \
/bin/sh ../config/install-sh -c -m 644 $file
/usr/local/share/man//$file || exit; \
done
make -C src install
/bin/sh ../config/mkinstalldirs /usr/local/pgsql/lib/pgxs/src
mkdir -p -- /usr/local/pgsql/lib/pgxs/src
/bin/sh ../config/install-sh -c -m 644 Makefile.global
/usr/local/pgsql/lib/pgxs/src/Makefile.global
/bin/sh ../config/install-sh -c -m 644 Makefile.port
/usr/local/pgsql/lib/pgxs/src/Makefile.port
/bin/sh ../config/install-sh -c -m 644 ./Makefile.shlib
/usr/local/pgsql/lib/pgxs/src/Makefile.shlib
/bin/sh ../config/install-sh -c -m 644 ./nls-global.mk
/usr/local/pgsql/lib/pgxs/src/nls-global.mk
make -C port install
/bin/sh ../../config/install-sh -c -m 644 libpgport.a
/usr/local/pgsql/lib
make -C timezone install
make -C ../../src/port all
make[3]: Nothing to be done for `all'.
gcc -no-cpp-precomp -O4 -Wall -Wmissing-prototypes -Wpointer-arith
-Wendif-labels -fno-strict-aliasing zic.o ialloc.o scheck.o localtime.o
-L../../src/port -L/sw/lib/ -lpgport -lz -lreadline -lresolv -ldl -lm
-o zic.out
mkdir -p -- /usr/local/pgsql/share
./zic -d /usr/local/pgsql/share/timezone ./data/africa
./data/antarctica ./data/asia ./data/australasia ./data/europe
./data/northamerica ./data/southamerica ./data/pacificnew
./data/etcetera ./data/factory ./data/backward ./data/systemv
./data/solar87 ./data/solar88 ./data/solar89
make[2]: ./zic: Command not found
make[2]: *** [install] Error 127
make[1]: *** [install] Error 2
make: *** [install] Error 2
I did remove XCode 1.5, installed XCode 1.2, no difference. 8(
Well If you have an idea, I'd welcome it 8)
Have a nice day!
Will
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
---(end of broadcast)---
TIP 9: the planner will ignore your desire to
Re: [HACKERS] Adding a suffix array index
Hi Troels, This is not related to the database aspects of your question... But there are more than 4 possible letters in DNA sequences, 16 in fact. Depending on the accuracy of the DNA sequences you are storing, you may come across ambiguity DNA bases, so your type will have to take these into account. The possible letters (according to IUPAC rules) are listed at the bottom of this page http://gnomix.ansci.umn.edu/FASTA.html Cheers Adam Hello, I'm working on a thesis project where I explore the addition of a specialized, bioinformatics-related data type to a RDBMS. My choice of RDBMS is PostgreSQL, of course, and I've started by adding a dnaseq (DNA sequence) data type, using PostgreSQL's APIs for type additions. The idea is to try to make it practical and even attractive to work with DNA sequences in an RDBMS. My starting goal is to make it viable to work with sequences in the 50-500 million base range. Some may think that RDBMSes and long chunks of data don't match well. My opinion is that the increasing power of computers and RDBMS software should at some point make it possible to work with DNA sequences in a normal data management setting like a RDBMS, instead of solely using stand-alone tools and stand-alone data files. Anyways, it's an open question if my hypothesis is right. The basic parts of the type are pretty much done. Those interested may have a look at http://troels.arvin.dk/svn-snap/postgresql-dnaseq/ (the code organization needs some clean-up). The basic type implementation should be improved by adding more string functions and by implementing a set of specialized selectivity functions. Part of my current code concerns packing DNA characters: As the alphabet of DNA strings is very small (four characters), it seems like a straigt-forward optimization to store each character in two bits. A warning: This is my first C project, so please don't laugh too much (publicly) if you find strange constructs in my code... Although B-trees and hash indexes may be used with my dnaseq type, they aren't very interesting for long DNA sequences. I would like to add support for adding a suffix array or suffix tree based index to dnaseq columns where the user expects long sequences. My review of the latest academic work on indexing of long sequences indicates that suffix arrays are probably the way to go: Recent advances in suffix array algorithms make them more attractive than suffix trees (because the take up less space). And since the DNA data I'm currently trying to support aren't separated in words, a string B-tree doesn't seem to be relevant. My first and most immediate goal is to support efficient answering of a question like which rows contain the sequence TTGACCACTTG in column foo?. I have to immediate problems: 1. The algoriths I've found don't indicate a good way to update index arrays. So I'm thinking of implementing a sort of index-cluster which has one sub-index per indexed value. That way, I don't have to worry about updating a large index covering all the indexes values in the column. Is it conceivable to create such an index cluster? 2. Does someone know of interesting documentation (perhaps in the form of interesting code comments) which I should read, as a basis for creating a non-standard index type in PostgreSQL? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] 8.0.0beta1 initdb failure on OSX 10.3.5
Hi, just built and tried the regressions tests, but it fails here: == initializing database system == ./pg_regress: line 470: 10212 Trace/BPT trap $bindir/initdb -D $PGDATA -L $datadir --noclean $initdb_options $LOGDIR/initdb.log 21 pg_regress: initdb failed Examine ./log/initdb.log for the reason. make[2]: *** [check] Error 2 rm regress.o make[1]: *** [check] Error 2 make: *** [check] Error 2 The contents of ./log/initdb.log : dyld: /usr/local/install/postgresql-8.0.0beta1/src/test/regress/./tmp_check/instal l//usr/local/pgsql/bin/initdb can't open library: /usr/local/pgsql/lib/libpq.3.dylib (No such file or directory, errno = 2) There is certainly a file at .//src/test/regress/tmp_check/install/usr/local/pgsql/lib/libpq.3.dylib adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] One regression failure with 7.4.1 on Debian 3.0r2
I have one regression failure on 7.4.1, which does not occur with 7.4 [EMAIL PROTECTED] more src/test/regress/regression.diffs *** ./expected/random.out Thu Feb 13 05:24:04 2003 --- ./results/random.outTue Dec 23 20:19:40 2003 *** *** 25,31 GROUP BY random HAVING count(random) 1; random | count +--- ! (0 rows) SELECT random FROM RANDOM_TBL WHERE random NOT BETWEEN 80 AND 120; --- 25,32 GROUP BY random HAVING count(random) 1; random | count +--- ! 103 | 2 ! (1 row) SELECT random FROM RANDOM_TBL WHERE random NOT BETWEEN 80 AND 120; [EMAIL PROTECTED] uname -a Linux bugsdb 2.4.23 #1 SMP Tue Dec 23 12:29:42 GMT 2003 i686 unknown -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] 7.4 make failure on OSX
Hi, I suspect this a problem local to my machine, but I cannot compile with the --with-java option... It fails like so driver: [copy] Copying 1 file to /usr/local/install/postgresql-7.4/src/interfaces/jdbc/org/postgresql [echo] Configured build for the JDBC3 edition driver with SSL compile: BUILD FAILED file:/usr/local/install/postgresql-7.4/src/interfaces/jdbc/build.xml:114: Old driver was detected on classpath or in jre/lib/ext, please remove and try again. Total time: 6 seconds make[3]: *** [all] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 I have removed the driver from my old 7.3 installation... But it still fails like this. Any ideas how to fix this? Thanks Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.4 make failure on OSX ... Please ignore
Sorry, I did find the offending driver in the end... And it is running happily now. Sorry for the noise Adam Hi, I suspect this a problem local to my machine, but I cannot compile with the --with-java option... It fails like so driver: [copy] Copying 1 file to /usr/local/install/postgresql-7.4/src/interfaces/jdbc/org/postgresql [echo] Configured build for the JDBC3 edition driver with SSL compile: BUILD FAILED file:/usr/local/install/postgresql-7.4/src/interfaces/jdbc/build.xml:114: Old driver was detected on classpath or in jre/lib/ext, please remove and try again. Total time: 6 seconds make[3]: *** [all] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 I have removed the driver from my old 7.3 installation... But it still fails like this. Any ideas how to fix this? Thanks Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] JDBC with 7.4RC2
Should the jdbc driver compile ok with 7.4RC2? I configure like so ./configure --with-perl --with-java --with-libs=/sw/lib --with-includes=/sw/include But it fails with this compile: BUILD FAILED file:/usr/local/install/postgresql-7.4RC2/src/interfaces/jdbc/build.xml:114: Old driver was detected on classpath or in jre/lib/ext, please remove and try again. Total time: 4 seconds make[3]: *** [all] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 I think I have deleted all the old postgresql.jar files. Any ideas? Or is the jdbc driver no yet compatible with 7.4RC2? (This is on MacOSX 10.2.8) Thanks adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for port reports
On 24/10/03 4:37 pm, Bruce Momjian [EMAIL PROTECTED] wrote: It is time for people to report their port testing. Please test against current CVS or beta5 and report your 'uname -a'. The current list is at: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html All beta5 regression tests pass on [mrc1-003:] adam% uname -a Darwin mrc1-003.sghms.ac.uk 6.8 Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC Power Macintosh powerpc [mrc1-003:] adam% sw_vers ProductName:Mac OS X ProductVersion: 10.2.8 BuildVersion: 6R73 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Beta4 Tag'd and Bundled ...
Hi, Many of the regression tests are failing on my OSX 10.2.6 machine. I have put the regression.diffs file here http://bugs.sghms.ac.uk/downloads/regression.diffs Has this been seen before? Thanks adam Check her over and let me know if there are any problems ... will do a full general announce tomorrow for it ... ---(end of broadcast)--- TIP 8: explain analyze is your friend -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: max_connections/shared_buffers (was Re: [HACKERS] Beta4 Tag'd and
On 4/10/03 8:10 pm, Tom Lane [EMAIL PROTECTED] wrote: I said: Hm. The parallel regression tests require at least 20. I deliberately allowed initdb to select values as small as 10 on the theory that installing and not being able to run the parallel regression tests is better than not installing at all. Actually, after trying to reproduce the problem on my own OS X machine, I realize that it's a little more subtle than I thought. The Darwin port does not use SysV semaphores at all (it uses Posix semaphores) and so the resource restriction you're hitting must actually be the max-shared-memory limit, rather than number-of-semaphores as I first assumed. max_connections does have an impact on shared memory size, though not as large as shared_buffers has. Therefore, the real problem is that initdb initially probes for a workable number of shared_buffers while using max_connections=5, and then it selects max_connections while holding shared_buffers constant. I was thinking that a small max_connections would prevent us from mistakenly choosing tiny shared_buffers when the system's real restriction is on number of semaphores. But what we seem to have here is that the selected number of buffers was just a little under the system's max-shared-memory limit, so that max_connections could be raised to 10 but not to 20. (BTW, on my OS X machine, with out-of-the-box configuration, initdb selects shared_buffers 400 and max_connections 20. I'm guessing that you had either a nondefault shared memory limit, or some other process using shared memory.) These are my current settings sysctl -w kern.sysv.shmmax=4194304 sysctl -w kern.sysv.shmmin=1 sysctl -w kern.sysv.shmmni=32 sysctl -w kern.sysv.shmseg=8 sysctl -w kern.sysv.shmall=1024 This is a laptop so I have quite a few other apps running, including my current PostgreSQL installation (7.2.3), the settings of which are #max_connections = 32 shared_buffers = 100 Let me know if you need any more info? Thanks Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Beta4 Tag'd and Bundled ...
Hi, Many of the regression tests are failing on my OSX 10.2.6 machine. I have put the regression.diffs file here http://bugs.sghms.ac.uk/downloads/regression.diffs Has this been seen before? Thanks adam Check her over and let me know if there are any problems ... will do a full general announce tomorrow for it ... ---(end of broadcast)--- TIP 8: explain analyze is your friend -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Beta4 Tag'd and Bundled ...
On 4/10/03 5:16 pm, Tom Lane [EMAIL PROTECTED] wrote: Adam Witney [EMAIL PROTECTED] writes: Many of the regression tests are failing on my OSX 10.2.6 machine. I have put the regression.diffs file here http://bugs.sghms.ac.uk/downloads/regression.diffs Seems to be all ! psql: FATAL: sorry, too many clients already What did initdb set your max_connections to? regards, tom lane From src/test/regress/log/initdb.log selecting default max_connections... 10 Is this the info you are asking for? adam ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] contrib Makefile's and OS X
PL/R compiles and installs ok on my OS X 10.2.4, the corresponding line is
gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes
-Wmissing-declarations -flat_namespace -bundle -undefined suppress plr.o
pg_conversion.o pg_backend_support.o pg_userfuncs.o pg_rsupport.o -L/sw/lib
-L/sw/lib/R/bin -lR -o libplr.so.0.0
adam
I've written PL/R to make use of the contrib build system, and modelled
its Makefile after other contrib modules. One user who tried installing
PL/R under OS X sent me this:
The makefile does
gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes
-Wmissing-declarations -fno-common -install_name
/usr/local/pgsql/lib/libplr.0.dylib -dynamiclib plr.o
pg_conversion.o pg_backend_support.o pg_userfuncs.o pg_rsupport.o
-L../../src/interfaces/libpq -L/usr/local/lib/R/bin -lR -o
libplr.0.0.dylib
In OS X this should be
gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes
-Wmissing-declarations -fno-common -bundle -flat_namespace -undefined
suppress plr.o pg_conversion.o pg_backend_support.o pg_userfuncs.o
pg_rsupport.o -L../../src/interfaces/libpq -L/usr/local/lib/R/bin -lR
-o plr.so
Below is the Makefile. The key problem is that I need to get a bundle
built instead of a dynamiclib, or so I am told.
Any idea what I'm doing wrong?
Thanks,
Joe
8-
r_libdir = ${R_HOME}/bin
r_includespec = ${R_HOME}/include
subdir = contrib/plr
top_builddir = ../..
include $(top_builddir)/src/Makefile.global
override CPPFLAGS := -I$(srcdir) -I$(r_includespec) $(CPPFLAGS)
override CPPFLAGS += -DPKGLIBDIR=\$(pkglibdir)\ -DDLSUFFIX=\$(DLSUFFIX)\
rpath :=
MODULE_big := plr
PG_CPPFLAGS := -I$(r_includespec)
SRCS+= plr.c pg_conversion.c pg_backend_support.c
pg_userfuncs.c pg_rsupport.c
OBJS:= $(SRCS:.c=.o)
SHLIB_LINK := -L$(r_libdir) -lR
DATA_built := plr.sql
DOCS:= README.plr
REGRESS := plr
EXTRA_CLEAN := doc/HTML.index
include $(top_srcdir)/contrib/contrib-global.mk
8-
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] 7.3b3 on MacOSX 10.2.1
On 29/10/02 6:02 pm, Tom Lane [EMAIL PROTECTED] wrote: Adam Witney [EMAIL PROTECTED] writes: Just to update the list of supported platforms, 7.3b3 compiles and passes all the regression tests on MacOSX 10.2.1 Although don't know if this is relevant but this appears when running the tests: parallel group (20 tests): ./pg_regress: fork: Resource temporarily unavailable ./pg_regress: fork: Resource temporarily unavailable comments lseg box path timetz point circle reltime tinterval date inet interval timestamp time abstime polygon timestamptz oidjoins This suggests that you are hitting the per-user limit on the number of processes you can have; try raising that limit. I'd expect one of the tests not to have been run when that message appears; did you really get successful matches for all tests? regards, tom lane It appears that my ignorance got the better of me It was the first time I had run the regression tests on any PostgreSQL installation. But I think I am getting the same problems as others. below is the last part of the regression tests (I had taken the All 15 tests passed as a success!) Let me know if I can be of any assistance in further checking this out == running regression test queries== parallel group (13 tests): char int4 boolean name varchar float8 bit text int2 oid int8 float4 numeric boolean ... ok char ... ok name ... ok varchar ... ok text ... ok int2 ... ok int4 ... ok int8 ... ok oid ... ok float4 ... ok float8 ... ok bit ... ok numeric ... ok test strings ... ok test numerology ... ok parallel group (20 tests): ./pg_regress: fork: Resource temporarily unavailable ./pg_regress: fork: Resource temporarily unavailable comments lseg box path timetz point circle reltime tinterval date inet interval timestamp time abstime polygon timestamptz oidjoins== shutting down postmaster == == All 15 tests passed. == rm regress.o -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Request for supported platforms
On 29/10/02 1:50 pm, Tom Lane [EMAIL PROTECTED] wrote: Bruce Momjian [EMAIL PROTECTED] writes: Strange. I just got report from another OSX 10.2.1 user saying regression tests passed: 10.2.1, Adam Witney ([EMAIL PROTECTED] The proper value seems to be: 15.3864610140472 or 15.3864610140473 in ./expected/geometry-powerpc-darwin.out. Which is it, folks? The existing geometry file is exactly correct on my laptop (Powerbook G3 using OSX 10.1). I am not sure whether the differences some users have reported are due to hardware or OS version differences. We need to figure that out and refine the resultmap, not just change the existing file. I don't have a lot of experience with this stuff, but let me know what to try and I will try it. (Using a Powerbook G4 OSX 10.2.1) Cheers adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] 7.3b3 on MacOSX 10.2.1
Just to update the list of supported platforms, 7.3b3 compiles and passes all the regression tests on MacOSX 10.2.1 Although don't know if this is relevant but this appears when running the tests: parallel group (20 tests): ./pg_regress: fork: Resource temporarily unavailable ./pg_regress: fork: Resource temporarily unavailable comments lseg box path timetz point circle reltime tinterval date inet interval timestamp time abstime polygon timestamptz oidjoins Cheers Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
