Re: [HACKERS] spi and other languages
Sibtay Abbas [EMAIL PROTECTED] writes: We can call SQL statements like SPI_Execute(SELECT * FROM sometable) from the spi interface. My question is that can we enter other procedural languages as well, like pgplsql statements. You can call a function written in another procedural langauge by executing a SELECT: SPI_Execute(SELECT myfunction()) But you can't execute arbitrary code in other langauges using SPI (of from the client side, for that matter)--it has to be wrapped up in a function. -Doug ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] apparent problem on linux/s390
Nicolai Tufar [EMAIL PROTECTED] writes: Hercules is a tested and proved emulator but I have a vague doubt that it's IEEE FPU emulation may be slightly different from the real iron's one. FWIW, I get clean regression test passes on a real z900 at Red Hat, in both s390 and s390x (32- and 64-bit) modes. I'm not sure what that means --- it could be that Red Hat Linux doesn't use the hardware floating point, or it could be that their version of glibc knows how to deal with corner cases like NaNs on this hardware. Or it could be that Hercules is broken. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] [SECURITY] Fedora Core 2 Update: mysql-3.23.58-9.1 (fwd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Heh heh heh :-) - -- Forwarded message -- Date: Wed, 08 Dec 2004 12:33:48 -0500 From: Tom Lane [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [SECURITY] Fedora Core 2 Update: mysql-3.23.58-9.1 - - Fedora Update Notification FEDORA-2004-530 2004-12-08 - - Product : Fedora Core 2 Name: mysql Version : 3.23.58 Release : 9.1 Summary : MySQL client programs and shared libraries. Description : MySQL is a multi-user, multi-threaded SQL database server. MySQL is a client/server implementation consisting of a server daemon (mysqld) and many different client programs and libraries. This package contains the MySQL client programs, the client shared libraries, and generic MySQL files. - - * Tue Oct 12 2004 Tom Lane [EMAIL PROTECTED] 3.23.58-9.1 - - fix security issues CAN-2004-0835, CAN-2004-0836, CAN-2004-0837 (bugs #135372, 135375, 135387) - - fix privilege escalation on GRANT ALL ON `Foo\_Bar` (CAN-2004-0957) - - fix multilib problem with mysqlbug and mysql_config - - adjust chkconfig priority per bug #128852 - - remove bogus quoting per bug #129409 (MySQL 4.0 has done likewise) - - add sleep to mysql.init restart(); may or may not fix bug #133993 - - fix low-priority security issues CAN-2004-0388, CAN-2004-0381, CAN-2004-0457 (bugs #119442, 125991, 130347, 130348) - - fix bug with dropping databases under recent kernels (bug #124352) - - This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/2/ 631ed84a7379164d0fbfb92b69016285 SRPMS/mysql-3.23.58-9.1.src.rpm 4a0aec6e6dbe79edd30eb441c2f142d6 x86_64/mysql-3.23.58-9.1.x86_64.rpm 36dccd9a66e5cea5350dce364bcabd35 x86_64/mysql-server-3.23.58-9.1.x86_64.rpm dd48b7d5690d051d53958613be03d995 x86_64/mysql-devel-3.23.58-9.1.x86_64.rpm 96805f6f4016ea429a61c9fd1b048f13 x86_64/mysql-bench-3.23.58-9.1.x86_64.rpm 6226ba82b2bdfe91c3b6b966340cb117 x86_64/debug/mysql-debuginfo-3.23.58-9.1.x86_64.rpm 643a2d1e297fc56c133e231b627ab9fa i386/mysql-3.23.58-9.1.i386.rpm 4dd68414fe1096b703f7f8e155ef227f i386/mysql-server-3.23.58-9.1.i386.rpm 09beb1f36eff820937e2a7193559b8d9 i386/mysql-devel-3.23.58-9.1.i386.rpm 63991ec7997909cddfa114d244353434 i386/mysql-bench-3.23.58-9.1.i386.rpm 8d99d621e6259d4df98c242c9030 i386/debug/mysql-debuginfo-3.23.58-9.1.i386.rpm This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command. - - - -- fedora-announce-list mailing list [EMAIL PROTECTED] http://www.redhat.com/mailman/listinfo/fedora-announce-list -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBt32Xtl86P3SPfQ4RAvmGAKDjC4Qdu0E20ohd0vARtCY/oMr+IgCfYndW EQHslhLJ5prwGCFWfDMAL9Y= =VCiB -END PGP SIGNATURE- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Small fix for 7.2.6/contrib/seg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
While trying to build 7.2.6 FC1 RPMs due to a request from Pierlugi today,
I saw an error in contrib/seg. This small patch fixed the typo and we can
build the RPMs now. Could you please apply it to 7.2?
===
- --- segparse.y.orig 2004-12-08 16:31:56.406802528 +0200
+++ segparse.y 2004-12-08 16:32:13.773162440 +0200
@@ -97,7 +97,6 @@
((SEG *)result)-l_ext = ( $1.ext ? $1.ext : '\0' );
((SEG *)result)-u_ext = '-';
}
- - ;
|
RANGE boundary {
((SEG *)result)-lower = -HUGE;
===
Regards,
- --
Devrim GUNDUZ
devrim~gunduz.orgdevrim.gunduz~linux.org.tr
http://www.tdmsoft.com
http://www.gunduz.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFBtygItl86P3SPfQ4RAgstAKDqAgwuPiIFWxZGOkuNBiqJsLkKbQCguaqi
vur5mirSNuFiyNwRFOvUQ6c=
=+FMA
-END PGP SIGNATURE-
---(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
[HACKERS] old-style handler problem
hi everyone
i ve added my own pl language in postgresql. i ve
followed the process mentioned in the documentation.
for the handler function i ve followed the following
template
PG_FUNCTION_INFO_V1(myhandler);
Datum
plsample_call_handler(PG_FUNCTION_ARGS)
{
Datum rv;
...my code
return rv;
}
then i created a function using my language...but when
i invoked it later on with SELECT funcName() i
received the following error
ERROR: language 25450 has old-style handler
why am i getting this message and how can it be
rectified...thank you
__
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] apparent problem on linux/s390
Meanwhile, if anyone knows of real big iron that could join the buildfarm that would also be good. I can't put it in the buildfarm ;-) but I have access to real s390 hardware inside Red Hat. I'll try to run a test build and see whether the regression tests pass. I would expect that s390 floating point is not even remotely IEEE-compliant; they'd have stuck with the S/360 behavior which predates the IEEE spec by probably 20 years. Whether it's worth generating variant regression files for this arch, I don't know. I think that IEEE float numbers are available on S390 G5 and newer machines. Dan ---(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] apparent problem on linux/s390
Maybe we should mark the buildfarm member as s390 emulator ? It could be. But we'd rather use the full specification, Hercules 2.37, ESAME S390 architecture, 31 bit mode, running Debian Linux Woody Full support for IEEE float number instructions was added into Hercules during last weeks of november. So you could try to recompile the last Hercules sources from CVS. Dan ---(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] branch for 8.0?
Peter Eisentraut [EMAIL PROTECTED] writes: I'm in favor of waiting until the release. Well, if we can hold to the Dec 15 release date, it's only a week's difference ... so I don't care much either way. Are you concerned about having to double-patch the last-minute translation updates? regards, tom lane ---(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] Status of server side Large Object support?
On E, 2004-11-29 at 02:22, David Garamond wrote:
Joe Conway wrote:
Not if the column is storage type EXTERNAL. See a past discussion here:
http://archives.postgresql.org/pgsql-general/2003-07/msg01447.php
what is the reasoning behind this syntax?
ALTER TABLE [ ONLY ] table [ * ]
ALTER [ COLUMN ] column SET STORAGE
{ PLAIN | EXTERNAL | EXTENDED | MAIN }
I find it nonintuitive and hard to remember. Perhaps something like this
is better (I know, it's probably too late):
ALTER [ COLUMN ] column SET STORAGE { INLINE | EXTERNAL }
ALTER [ COLUMN ] column SET COMPRESSION { YES | NO }
It wold also be beneficial if the threshold size of moving the column to
TOAST (either COMPRESS or EXTERNAL) could be set on a per-column basis
This is a design decision on the same lavel as the others
Hannu
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] apparent problem on linux/s390
On Tue, 07 Dec 2004 13:51:36 -0500, Tom Lane [EMAIL PROTECTED] wrote: FWIW, I get clean regression test passes on a real z900 at Red Hat, in both s390 and s390x (32- and 64-bit) modes. I'm not sure what that means --- it could be that Red Hat Linux doesn't use the hardware floating point, or it could be that their version of glibc knows how to deal with corner cases like NaNs on this hardware. Or it could be that Hercules is broken. Too bad :( I had great confidence in Hercules emulator. This is from official Hercules FAQ: ``The following standard feature has been partially implemented: * Binary Floating-Point instructions '' I am playing with -msoft-float gcc option which disables hawdware floating-piont instructions and uses glibc's ones instead but I get the following error: /tmp/ccOWrBZJ.o: In function `main': /tmp/ccOWrBZJ.o(.text+0x40): undefined reference to `__extendsfdf2' collect2: ld returned 1 exit status Doeas somebody know in what library `__extendsfdf2' is? Thanks in advance, Nicolai ---(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: [Testperf-general] Re: [HACKERS] 8.0beta5 results w/ dbt2
On Mon, Dec 06, 2004 at 07:52:37PM +, Simon Riggs wrote: Varying bgwriter_maxpages upwards should take performance higher. I have 2 runs now. I for both tests, I have bgwriter_percent=100, checkpoint_segments=8192, checkpoint_timout=600, debug_shared_buffers=10, log_min_messages=debug1 and varied bgwriter_maxpages. http://www.osdl.org/projects/dbt2dev/results/dev4-010/206/ bgwriter_maxpages=100 (default) throughput 3816.51 http://www.osdl.org/projects/dbt2dev/results/dev4-010/207/ bgwriter_maxpages=1000 throughput 3865.50 Another 1% change in overall throughput. I did catch in the oprofile output that StrategyDirtyBufferList moved down the list a bit when I increased bgwriter_maxpages. Mark ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] V8 Beta 5 on AIX
However, one thing we can do is to try this in Makefile.aix: # AIX needs threads for everything that uses libpq LIBS += $(PTHREAD_LIBS) That is going to enable thread libs for all linking including the backend, but it might work. That is certainly wrong. The correct thing is to add PTHREAD_LIBS to all and only those links that include libpq. I suspect that the cc_r You mean like attached patch ? That is safe and can be applied. My machine has problems with two configure tests with --enable-thread-safety. 1. the snprintf long long int check that uses int64 as variable name which is a typedef in sys/inttypes.h 2. whether strerror_r returns int check fails with a redefine of named function from string.h No idea how to fix those, but workaround is easy :-( -lpthread can be removed from PTHREAD_LIBS, the lib is a compat symlink to -lpthreads, I guess it does not hurt eighter. Andreas pg_aix_pthreads.patch Description: pg_aix_pthreads.patch ---(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] V8 Beta 5 on AIX
On Mon, Dec 06, 2004 at 08:07:00PM -0500, Bruce Momjian wrote: Yea, we needed this problem report during beta, not RC. For the record, there _was_ such a problem report, for b3: http://archives.postgresql.org/pgsql-hackers/2004-10/msg00046.php A -- Andrew Sullivan | [EMAIL PROTECTED] A certain description of men are for getting out of debt, yet are against all taxes for raising money to pay it off. --Alexander Hamilton ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for port reports
Peter Eisentraut [EMAIL PROTECTED] writes: It's now time to fill the holes. Briefly, I'm looking for exit status 0 on ./configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ --with-perl --with-python --with-krb5 --with-pam -with-openssl make make install make check with PostgreSQL 8.0.0rc1 or later. If you know what you're doing, you can also try other options, but please tell what you did. All regression tests pass on all seven architectures supported by Red Hat Enterprise Linux 3AS: i386generic Intel ia64Itanium x86_64 AMD ppc IBM pSeries ppc64 pSeries 64-bit s390IBM zSeries s390x zSeries 64-bit I did not test --with-tcl --with-python --with-krb5 --with-pam --with-openssl, for lack of installed packages, but since this is basically Linux I doubt there's much to be learned there. (If there is any problem with building with those packages added, I'll find out when I try to make Red Hat's RPMs ;-)) PostgreSQL 8.0.0rc1 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-47) PostgreSQL 8.0.0rc1 on ia64-unknown-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-24) PostgreSQL 8.0.0rc1 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-34) PostgreSQL 8.0.0rc1 on powerpc-unknown-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-38) PostgreSQL 8.0.0rc1 on powerpc64-unknown-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-38) PostgreSQL 8.0.0rc1 on s390-ibm-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-47) PostgreSQL 8.0.0rc1 on s390x-ibm-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-47) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [Testperf-general] Re: [HACKERS] 8.0beta5 results w/ dbt2
On Tue, Dec 07, 2004 at 09:12:18AM +, Simon Riggs wrote: Not sure, as yet, what is causing effect 2. It's not related to the kernel, but is related to user CPU and I/O waits and effects all tables in proportion to their overall I/O usage. Some evidence that it becomes more pronounced as CPU utilisation peaks, possibly increasing slightly in frequency once this occurs: maybe the cache filling? I never vacuum during the test. Is it possible that all the updates and inserts would affect this? Mark ---(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] somebody working on: Prevent default re-use of sysids for dropped users and groups?
Am 07.12.2004 um 19:24 schrieb Tom Lane: Matthias Schmidt [EMAIL PROTECTED] writes: By the way: Do you have an idea about a small or medium sized task from the TODO-List for a newbee, which gets me up to speed?(!Win32) A lot of the tasks listed under DATA TYPES are fairly self-contained problems ... but what draws your interest? I think most of the tasks that are on TODO are there either because they're hard problems, or because nobody was very interested in them. Unfortunately they are not marked as to which is which :-(. Make a list of things you find interesting, and we can tell you if they're very hard or already claimed. regards, tom lane Hi Tom, this is a list of things I'm interested in: 1) Allow administrators to safely terminate individual sessions Right now, SIGTERM will terminate a session, but it is treated as though the postmaster has paniced and shared memory might not be cleaned up properly. A new signal is needed for safe termination. 2) Add a function that returns the 'uptime' of the postmaster 3) Have SHOW ALL and pg_settings show descriptions for server-side variables to be honest I'm only looking for a particular task to get things started. cheers, Matthias -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] first pgAdmin 1.3 snapshot
At this very moment, the first snapshot of pgAdmin III 1.3 is uploading, which includes the pgsql configuration file editor. For pginstaller purposes, the command line pgadmin3 -c pgsql-datadir or pgadmin3 -ch pgsql-dir\pg_hba.conf or pgadmin3 -cm pgsql-dir\postgresql.conf handles the configuration files. If pginstaller should have additional/different requirements, please let us know. Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] How can I recovery old Data from files and
I already reinstall old version of PostgreSQL. However I still cannot run PostgreSQL service after I reinstall on many time. I think that I cannot use pg_dump or all command without PostgreSQL service running. So What thing I can do now? Andrew Dunstan [EMAIL PROTECTED] 7/12/2004 10:18:19 pm Premsun Choltanwanich wrote: I got some problem on PostgreSQL 8 for windows so I uninstall and reinstall it again. Before I uninstall PostgreSQL 8 I already backup all files and folders (copy all to other place). The problem is how can I restore by use files and folders that I already backup. If I try to restore by put all of it back it will be make a same error. I just want to restore only DATA (databases, functions, views, users, group etc). Please suggest me that How can I recovery old Data from files and folders on windows? PostgreSQL does not work like that. You should have backed up using pg_dump before uninstalling. File system backup won't work across catalog versions. In fact, your best bet is probably to reinstall the old version so you can start the server and run pg_dump. cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] apparent problem on linux/s390
On Tue, Dec 07, 2004 at 10:37:36AM +0200, Nicolai Tufar wrote: On Mon, 06 Dec 2004 19:15:23 -0500, Andrew Dunstan [EMAIL PROTECTED] wrote: problems apparently with NaNs, infinities and negative zeros. Sure smells more like an IEEE issue than a postgresql issue (built for IBM FP rather than IEEE? Dodgy bugs in the emulator?). I am the owner of this baby. It is not an actual mainframe, it is Hercules emulator running on AthlonXP 2500+ producing 20-25 MIPS of pure mainframe horsepower! On bootup Linux reports 130 BogoMIPS and OS/390 reports 40 MIPS. We all know that mainframe MIPS != mini MIPS. Anyways, a full compile of PostgreSQL source takes about 300 minutes. I run it overnight. Hercules is a tested and proved emulator but I have a vague doubt that it's IEEE FPU emulation may be slightly different from the real iron's one. Are there test suites to check if a linux's math functions confirm to the standards. I may need to run one of them first. IIRC older S390s don't do IEEE FP at all, and it's done via traps to the OS. Are you emulating the S390 IEEE FP hardware option or are you emulating non-IEEE hardware, with IEEE fixup in OS390? Paranoia by Dr Kahan is the classic IEEE compliance tester http://www.netlib.org/paranoia/ but I've also had a lot of success with the softlib based tester at http://www.jhauser.us/arithmetic/TestFloat.html. Cheers, Steve ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Test
Sorry - please ignore. ---(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] 8.0.0beta5 FailedAssertion (Crash) when casting composite types
I wrote: The cause of this failure is that parse_coerce.c thinks that a child table's rowtype is binary-compatible with its parent's rowtype: ... The Really Clean And Correct fix to this, IMHO, would be to invent a new expression node type that represents coercing a rowtype expression to a different rowtype. Execution of this node would disassemble and reassemble the tuple Datum, using code not too much different from execJunk.c, to produce the right column order and the right rowtype OID label. However that seems much too large a change for post-RC. (You could also argue that it requires an initdb, though I'd take the position that it doesn't because there are no working databases that would be affected.) A less clean but much more localized fix would be to cause ExecEvalExpr to do that work when it finds a RelabelType node whose output type is a composite type. (We could arrange to lookup the pg_type entry only once per query, during ExecInitExpr, so the performance hit on normal uses of RelabelType wouldn't be too bad.) A rough estimate is that this would require about 100 lines of new code in execQual.c, much of which could be adapted from other places. I developed a patch based on the second approach, but eventually realized that it doesn't quite close the gap. The problem is that there are quite a few places that know that RelabelType is a run-time no-op and feel free to ignore it. We could possibly hack each one to check whether the result type is composite or not, but that seems unlikely to provide a trustworthy fix. I now think that we don't really have any choice but to go with the clean solution and represent rowtype coercion as a new node type. As I said above, I intend to treat this as a non-initdb-forcing change, unless anyone vehemently objects. regards, tom lane ---(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] somebody working on: Prevent default re-use of sysids for dropped users and groups?
Matthias Schmidt [EMAIL PROTECTED] writes: By the way: Do you have an idea about a small or medium sized task from the TODO-List for a newbee, which gets me up to speed?(!Win32) A lot of the tasks listed under DATA TYPES are fairly self-contained problems ... but what draws your interest? I think most of the tasks that are on TODO are there either because they're hard problems, or because nobody was very interested in them. Unfortunately they are not marked as to which is which :-(. Make a list of things you find interesting, and we can tell you if they're very hard or already claimed. regards, tom lane ---(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] regression script/makefile exit failure
Further investigation has shown that the exit/trap idiom used in pg_regress.sh is less than 100% portable. The following shell script has been seen to produce incorrect output on both Cygwin and FreeBSD: #!/bin/sh trap ' st=$? echo status = $st exit $st ' 0 (exit 9); exit I'm not sure how we get a portable solution (other than maybe converting the shell script to perl). cheers andrew I wrote: I have seen several cases where either pg_regress appears not to exit with the expected non-zero exit status or make check does not apparently exit with the expected non-zero status. In particular, I've seen it on cygwin, windows, and have at least a suspicion of it happening on FreeBSD. The apparently offending code is this: message initializing database system [ $debug = yes ] initdb_options='--debug' $bindir/initdb -D $PGDATA -L $datadir --noclean $initdb_options $LOGDIR/initdb.log 21 if [ $? -ne 0 ] then echo echo $me: initdb failed echo Examine $LOGDIR/initdb.log for the reason. echo (exit 2); exit fi and it's called from this makefile target: check: all -rm -rf ./testtablespace mkdir ./testtablespace $(SHELL) ./pg_regress --temp-install --top-builddir=$(top_builddir) --schedule=$(srcdir)/parallel_schedule --multibyte=$(MULTIBYTE) $(MAXCONNOPT) The practical consequence of this is that instead of failing at this stage, the buildfarm script continues on until it somewhat inexplicably fails at the initdb stage. Now, perhaps I'm calling it wrong, but I don't think so. The relevant perl code is this: my @makeout = `cd $pgsql/src/test/regress $make check 21`; my $status = $? 8; which idiom seems to work as expected everywhere else quite happily. And in fact I've seen make check fail as expected on other failure paths (such as not matching the expected result.) Anyone have any penetrating thoughts? cheers andrew ---(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] branch for 8.0?
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: There was some talk of branching REL8_0_STABLE after 8.0.0rc1 was released. Is that still the plan? I'm up for it, personally --- is everybody else ready? Should we wait another day or three? I'm in favor of waiting until the release. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] errmsg(... because ...)
Hackers, There are a bunch of error messages saying something like cannot foo because bar For example, errmsg(cannot assign to field \%s\ of column \%s\ because its type %s is not a composite type) What do you think of changing those to use errdetail in addition to errmsg? So this particular example would become something like errmsg(cannot assign to field \%s\ of column \%s\), errdetail(Its type %s is not a composite type.) There are some of them that should probably be left alone, like errmsg(terminating connection because of crash of another server process) I see around a dozen messages in the backend that could be changed like this. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La gente vulgar solo piensa en pasar el tiempo; el que tiene talento, en aprovecharlo ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for port reports
Peter Eisentraut wrote: Briefly, I'm looking for exit status 0 on ./configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ --with-perl --with-python --with-krb5 --with-pam -with-openssl (I would like the build farm members for Windows and Cygwin to use more feature-enabling options, because in those cases we really need the information about which extra features compile and work.) I have successfully added --with-perl --with-python --with-openssl to the buildfarm cygwin member. Currently --with-tcl is giving me link problems. I'm not sure how relevant krb5 and pam are - I suspect not. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] somebody working on: Prevent default re-use of sysids for dropped users and groups?
Am 06.12.2004 um 23:27 schrieb Tom Lane: schmidtm [EMAIL PROTECTED] writes: Do I get that right: the only reason to do max(sysid) or a user-supplied ID in CreateUser() (commands/user.c) is that we don't have the ability to get sequences over the *.BKI/initdb mechanism? No, that's not quite the direction of the problem. The real reason those facilities are there is so that you can deliberately create a user having a previously-used sysid. And the only reason why that is needed is that we don't have dependency tracking for references to users and groups. If you could be certain that there were no remaining references to a userid when it is dropped, there would be no need to be able to resurrect it. And that would mean that we could forget the whole sysid assignment mess and just use the regular OID generator to create unique IDs for users and groups. Using a shared sequence instead of max(sysid) would be merely an incremental improvement in the existing sysid assignment rules --- it wouldn't eliminate the entire kluge at one blow. So if Alvaro's thing works out, the shared-sequence problem becomes moot. Probably that's a good reason not to spend time on it just yet. regards, tom lane makes totally sense to me. Let's wait for Alvaro's stuff. By the way: Do you have an idea about a small or medium sized task from the TODO-List for a newbee, which gets me up to speed?(!Win32) The TODO-List is a good starting point, but I cannot figure out who works on what. cheers, Matthias -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(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] [SECURITY] Fedora Core 2 Update: mysql-3.23.58-9.1 (fwd)
On Thu, Dec 09, 2004 at 12:17:58AM +0200, Devrim GUNDUZ wrote: Heh heh heh :-) - -- Forwarded message -- Date: Wed, 08 Dec 2004 12:33:48 -0500 From: Tom Lane [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Well, working for Red Hat has the downside of having him waste time on MySQL, it seems ... -- Alvaro Herrera ([EMAIL PROTECTED]) ---(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] Call for port reports
./configure \ --prefix=/usr/local/pgsql/8.0rc1 \ --enable-thread-safety \ --with-tcl \ --with-perl \ --with-python \ --with-krb5 \ --with-pam \ --with-openssl \ --with-includes=/sw/include/ \ --with-libraries=/sw/lib make check == All 96 tests passed. == test8=# select version() ; version PostgreSQL 8.0.0rc1 on powerpc-apple-darwin7.6.0, compiled by GCC gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666) (1 row) On Dec 6, 2004, at 7:00 PM, Peter Eisentraut wrote: I have started filling in the supported platform list for the 8.0.0 release with the information from the build farm: http://developer.postgresql.org/docs/postgres/supported-platforms.html It's now time to fill the holes. Briefly, I'm looking for exit status 0 on ./configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ --with-perl --with-python --with-krb5 --with-pam -with-openssl make make install make check with PostgreSQL 8.0.0rc1 or later. If you know what you're doing, you can also try other options, but please tell what you did. (I would like the build farm members for Windows and Cygwin to use more feature-enabling options, because in those cases we really need the information about which extra features compile and work.) If your system provides multiple compilers (for example, a vendor compiler and GCC), test with all of them. Call configure as follows: ./configure CC=/foo/cc --prefix=... If your system has multiple compilation modes, such as 32 bit and 64 bit, it may be worth trying both. Report the output of SELECT version(); as well as a common name of the operating system under which it can be listed (e.g., the distributor, in case of a Linux-based system). -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html Patrick B. Kelly -- v: 484.557.0646 http://patrickbkelly.org ---(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] regression script/makefile exit failure
I have seen several cases where either pg_regress appears not to exit with the expected non-zero exit status or make check does not apparently exit with the expected non-zero status. In particular, I've seen it on cygwin, windows, and have at least a suspicion of it happening on FreeBSD. The apparently offending code is this: message initializing database system [ $debug = yes ] initdb_options='--debug' $bindir/initdb -D $PGDATA -L $datadir --noclean $initdb_options $LOGDIR/initdb.log 21 if [ $? -ne 0 ] then echo echo $me: initdb failed echo Examine $LOGDIR/initdb.log for the reason. echo (exit 2); exit fi and it's called from this makefile target: check: all -rm -rf ./testtablespace mkdir ./testtablespace $(SHELL) ./pg_regress --temp-install --top-builddir=$(top_builddir) --schedule=$(srcdir)/parallel_schedule --multibyte=$(MULTIBYTE) $(MAXCONNOPT) The practical consequence of this is that instead of failing at this stage, the buildfarm script continues on until it somewhat inexplicably fails at the initdb stage. Now, perhaps I'm calling it wrong, but I don't think so. The relevant perl code is this: my @makeout = `cd $pgsql/src/test/regress $make check 21`; my $status = $? 8; which idiom seems to work as expected everywhere else quite happily. And in fact I've seen make check fail as expected on other failure paths (such as not matching the expected result.) Anyone have any penetrating thoughts? cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] buildfarm build failure: icc7 + --enable-cassert
It looks like --enable-cassert isn't handled properly under icc7 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herringdt=2004-12-07%2016:30:44 -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] old-style handler error
i have added my own pocedural language in postgresql. by using the Create function command i ve also written a procedure in that language. now when invoke that function with SELECT (func_name) i receive the following error message ERROR: language 17254 has old-style handler. __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
