[HACKERS] 7.5-dev, pg_dumpall, dollarquoting

2004-06-18 Thread Stefan Kaltenbrunner
Hi! since we have a lot of databases here that suffer from pg_dump's deficits in 7.3 and 7.4 regarding dependencies, we tried pg_dump from the upcoming 7.5 release. This version works much better, but it is not possible to dump a complete cluster using pg_dumpall in a 7.3 or 7.4 compatible way

[HACKERS] Tablespace issues (comment on ,moving indexes)

2004-08-09 Thread Stefan Kaltenbrunner
Hi! I'm currently working on the psql tab-complete code, fixing quite a lot of bugs/annoyances in the process. One of the things I'm trying to do is syncing the available commands in psql with the docs - during this work I found two irritating things regarding tablespaces: 1. there is no

Re: [HACKERS] tablespace and sequences?

2004-08-17 Thread Stefan Kaltenbrunner
Fabien COELHO wrote: (3) psql auto completion does not have CREATE/DROP TABLESPACE in its list. I have already posted a patch for this(http://candle.pha.pa.us/mhonarc/patches/msg0.html) and afaik it is on Bruce's Beta-TODO list too. Stefan ---(end of

Re: [HACKERS] Regression test failures

2004-08-28 Thread Stefan Kaltenbrunner
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I am still seeing random regression test failures on my SMP BSD/OS machine. It basically happens when doing 'gmake check'. I have tried running repeated tests and can't get it to reproduce, but when checking patches it has happened perhaps

[HACKERS] -HEAD build failure on OpenBSD 3.6-current/Sparc64 +patch

2004-10-04 Thread Stefan Kaltenbrunner
this one got caught by the testfarm as well - it looks like the openbsd-specific makefile is missing a -fPIC for the Sparc platform(I would assume that at least NetBSD/sparc is affected too but I don't have access to such a system to test on). And I also think that -shared is now

Re: [HACKERS] -HEAD build failure on OpenBSD 3.6-current/Sparc64

2004-10-05 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: this one got caught by the testfarm as well - it looks like the openbsd-specific makefile is missing a -fPIC for the Sparc platform(I would assume that at least NetBSD/sparc is affected too but I don't have access to such a system

Re: [HACKERS] -HEAD build failure on OpenBSD 3.6-current/Sparc64

2004-10-05 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Tom Lane wrote: Why did you remove -DPIC ? uhm partly because I sent the wrong patch and partly because I didn't understood what that to do anyway(in the !Sparc case). The only place I can find on my machine where defining PIC seems

[HACKERS] -HEAD regression failure on OpenBSD 3.6-current/x86

2004-10-31 Thread Stefan Kaltenbrunner
One of my boxes(emu) on the buildfarm fails to pass the float8 regressiontest: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=emudt=2004-10-31%2003:35:02 the interesting thing is that spoonbill (slightly older OpenBSD-current/Sparc64) passes this test(but fails contribcheck later on):

Re: [HACKERS] OpenBSD/Sparc status

2004-11-19 Thread Stefan Kaltenbrunner
Tom Lane wrote: The answer is: it's a gcc bug. The attached program should print x = 12.3 y = 12.3 but if compiled with -O or -O2 on Stefan's machine, I get garbage: $ gcc -O ftest.c $ ./a.out x = 12.3 y = 1.47203e-39 woa - scary. I will report that to the OpenBSD-folks upstream - many thanks

Re: [HACKERS] OpenBSD/Sparc status

2004-11-21 Thread Stefan Kaltenbrunner
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Meanwhile, what do we do? Turn off -O in src/template/openbsd for some/all releases? Certainly not. This problem is only known to exist in one gcc version for one architecture, and besides it's only affecting (so far as we can tell) one

Re: [HACKERS] OpenBSD/Sparc status

2004-11-23 Thread Stefan Kaltenbrunner
Tom Lane wrote: Darcy Buskermolen [EMAIL PROTECTED] writes: I can confirm this behavior on Solaris 8/sparc 64 as well. bash-2.03$ gcc -m64 -O2 test.c bash-2.03$ ./a.out x = 12.3 y = 2.51673e-42 bash-2.03$ gcc -m64 -O3 test.c bash-2.03$ ./a.out x = 12.3 y = 12.3 bash-2.03$ Hmm. I hadn't

Re: [HACKERS] OpenBSD/Sparc status

2004-11-23 Thread Stefan Kaltenbrunner
Darcy Buskermolen wrote: On November 19, 2004 10:55 am, you wrote: The answer is: it's a gcc bug. The attached program should print x = 12.3 y = 12.3 but if compiled with -O or -O2 on Stefan's machine, I get garbage: $ gcc -O ftest.c $ ./a.out x = 12.3 y = 1.47203e-39 $ gcc -v Reading specs from

[HACKERS] latest pgcrypto patches cause compile errors

2005-07-10 Thread Stefan Kaltenbrunner
looks like the latest pgcrypto-patches that just got applied cause widespread failures on the buildfarm machines: http://www.pgbuildfarm.org/cgi-bin/show_status.pl Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space

Re: [HACKERS] openbsd, plpython, missing threading symbols

2005-08-04 Thread Stefan Kaltenbrunner
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: The alternative is to say that plpython isn't supported on BSDen unless you choose to build an unthreaded libpython. I'm OK with that, but if that's what's done I think we should check for it up front at configure

[HACKERS] psql and ROLES

2005-08-07 Thread Stefan Kaltenbrunner
Hi, I'm currently working on syncing psql's tab-complete code with the docs especially wrt ROLES. while working on this I noticed the following things: *) there is no backslash command for getting a list of Roles (like \du \dg for Users and Groups) - I'm considering using \dr for that - does

Re: [HACKERS] psql and ROLES

2005-08-08 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: *) there is no backslash command for getting a list of Roles (like \du \dg for Users and Groups) - I'm considering using \dr for that - does that sound sensible ? We could just recycle \du and/or \dg for the purpose. If those

Re: [HACKERS] Changes improve the performance of INSERT and UPDATE

2005-08-13 Thread Stefan Kaltenbrunner
Tom Lane wrote: Hiroki Kataoka [EMAIL PROTECTED] writes: This small patch improves the performance of INSERT and UPDATE. By my machine, these changes raised the performance about 5%~10% in pgbench. BTW, in profiling the backend I've never seen PageAddItem take more than about 1% of the

[HACKERS] ALTER ROLES - questions

2005-08-15 Thread Stefan Kaltenbrunner
Hi! I played around with roles a bit today and noticed some minor things: ALTER ROLE seems to support ALTER ROLE name ROLE name - but that form is not mentioned in the docs: playground=# CREATE ROLE myrole; CREATE ROLE playground=# CREATE ROLE myrole2; CREATE ROLE playground=# ALTER ROLE myrole

Re: [HACKERS] Any MIPS assembly experts in the house?

2005-08-26 Thread Stefan Kaltenbrunner
Tom Lane wrote: I see the latest buildfarm result from a mipsel machine is failing: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfishdt=2005-08-26%2005:30:07 and the failure is this: TRAP: FailedAssertion(!(lock-shared 0), File: lwlock.c, Line: 456) LOG: server process (PID

Re: [HACKERS] Any MIPS assembly experts in the house?

2005-08-27 Thread Stefan Kaltenbrunner
Tom Lane wrote: I wrote: Can anyone spot the problem? If not I fear we'll have to revert this. After a bit of reading MIPS documentation, I found out that the proposed patch is exactly backward: it returns 1 if it gets the lock and 0 if the lock is already held :-( Because callers

[HACKERS] small pg_dumpall bug/warning in 8.1beta1

2005-08-28 Thread Stefan Kaltenbrunner
Hi! During testing of 8.1 I found that using pg_dumpall (-g) against a live 8.0 install that has at least one GROUP defined results in the following warning while it creates the CREATE ROLE statements in the dump: row number 0 is out of range 0..-1 To reproduce the problem it is enough to

Re: [HACKERS] small pg_dumpall bug/warning in 8.1beta1

2005-08-28 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: During testing of 8.1 I found that using pg_dumpall (-g) against a live 8.0 install that has at least one GROUP defined results in the following warning while it creates the CREATE ROLE statements in the dump: row number 0 is out

Re: [HACKERS] memcpy SEGV on AIX 5.3

2005-10-25 Thread Stefan Kaltenbrunner
Seneca Cunningham wrote: On an powerPC AIX 5.3 box, initdb from 8.1beta4 segfaults at src/backend/utils/hash/dynahash.c:673. No segfaults occur and all 98 regression tests pass if a test is added to see if keycopy is memcpy and if it is, go through a loop memcpying one byte at a time instead

Re: [HACKERS] memcpy SEGV on AIX 5.3

2005-10-26 Thread Stefan Kaltenbrunner
Stefan Kaltenbrunner wrote: Seneca Cunningham wrote: On an powerPC AIX 5.3 box, initdb from 8.1beta4 segfaults at src/backend/utils/hash/dynahash.c:673. No segfaults occur and all 98 regression tests pass if a test is added to see if keycopy is memcpy and if it is, go through a loop memcpying

Re: [HACKERS] 8.1 Release Candidate 1 Coming ...

2005-10-29 Thread Stefan Kaltenbrunner
Marc G. Fournier wrote: Tomorrow evening, I'm going to wrap up RC1, to announce it on Monday ... if anyone is sitting on *anything*, please say something before about midnight GMT ... hmm well -HEAD(and 8.0.4 too!) is broken on AIX 5.3ML3:

Re: [HACKERS] 8.1 Release Candidate 1 Coming ...

2005-10-29 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: hmm well -HEAD(and 8.0.4 too!) is broken on AIX 5.3ML3: http://archives.postgresql.org/pgsql-hackers/2005-10/msg01053.php [ shrug... ] The reports of this problem have not given enough information to fix it, and since it's

Re: [HACKERS] 8.1 Release Candidate 1 Coming ...

2005-10-31 Thread Stefan Kaltenbrunner
Mag Gam wrote: Is this issue only on AIX 5.3 ML1 thru ML 3? Does the build work fine with 5.2 (ALL MLs)? 5.3 ML1 works but it is affected by the System include Bug mentioned in our AIX-FAQ. ML3 is supposed to fix that specific problem but breaks in another more difficult way as it seems ...

Re: [HACKERS] Gist Recovery testing

2005-06-15 Thread Stefan Kaltenbrunner
Teodor Sigaev wrote: btree manages to avoid calling the index support functions during WAL restore --- can't you do the same? Perhaps you need to be including more information in the initial xlog records, so that the cleanup step has everything it needs. Or resort to brute-force search

Re: [HACKERS] hashtable crash (was Re: [PATCHES] Post-mortem: final 2PC patch)

2005-06-18 Thread Stefan Kaltenbrunner
Tom Lane wrote: dynahash.c thinks it should always copy 255 bytes of key, since that's what it was told the key size was ... but in this case the supplied search key has been allocated very close to the end of the process's memory, and there are not 255 bytes before the end of memory. aaah -

Re: [HACKERS] Gist Recovery testing

2005-06-19 Thread Stefan Kaltenbrunner
Oleg Bartunov wrote: On Wed, 15 Jun 2005, Stefan Kaltenbrunner wrote: Teodor Sigaev wrote: btree manages to avoid calling the index support functions during WAL restore --- can't you do the same? Perhaps you need to be including more information in the initial xlog records, so

Re: [HACKERS] What bison versions are installed on buildfarm machines?

2006-01-02 Thread Stefan Kaltenbrunner
Tom Lane wrote: Is there any way to find out $subject? I see that several of the buildfarm machines are choking on a patch I committed yesterday: guc-file.l: In function `ProcessConfigFile': guc-file.l:162: error: `YY_FLUSH_BUFFER' undeclared (first use in this function) guc-file.l:162:

Re: [HACKERS] What bison versions are installed on buildfarm machines?

2006-01-02 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: I just verified that -HEAD is broken on Debian Sarge 3.1 (nearly all of the failing buildfarm members are Debian Sarge 3.1 boxes) - and I just verified the Problem exists on i386 too. What flex version are they using? flex

Re: [HACKERS] What bison versions are installed on buildfarm machines?

2006-01-02 Thread Stefan Kaltenbrunner
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Not that hard to believe. 2.5.4 is what the major distributions are shipping. Even FC4 comes with 2.5.4a. The only reason I can see for this is that Flex is now considered a NON-GNU project. No, the major reason for it is that flex

Re: [HACKERS] What bison versions are installed on buildfarm machines?

2006-01-02 Thread Stefan Kaltenbrunner
Stefan Kaltenbrunner wrote: Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Not that hard to believe. 2.5.4 is what the major distributions are shipping. Even FC4 comes with 2.5.4a. The only reason I can see for this is that Flex is now considered a NON-GNU project. No, the major

[HACKERS] could not access status of transaction 0

2006-01-06 Thread Stefan Kaltenbrunner
Hi all! We seem to be getting this error (in german) once in a while on a rather complex database: FEHLER: konnte auf den Status von Transaktion 0 nicht zugreifen DETAIL: kann Datei /var/databases/postgres/data/pg_subtrans/57DA nicht erstellen: Die Datei existiert bereits which roughly

Re: [HACKERS] could not access status of transaction 0

2006-01-06 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: ERROR: could not access status of transaction 0 DETAIL: could not create file /var/databases/postgres/data/pg_subtrans/57DA: File exists and seems to be generated in backend/access/transam/slru.c it looks like we got those

[HACKERS] -HEAD compile failure on OpenBSD-current

2006-01-08 Thread Stefan Kaltenbrunner
Hi! -HEAD does not compile on my SMP i386 OpenBSD-current box (using a plain ./configure): gmake[4]: Leaving directory `/home/mastermind/source/pgsql/src/backend/utils/mb' /usr/local/bin/gmake -C misc SUBSYS.o gmake[4]: Entering directory `/home/mastermind/source/pgsql/src/backend/utils/mi sc'

Re: [HACKERS] Fw: Is anyone interested in getting PostgreSQL working

2006-01-08 Thread Stefan Kaltenbrunner
Jim Buttafuoco wrote: Hackers, I can confirm that HEAD does not initdb because of a SIGBUS as reported below by Martin Pitt @ debian (see his email below). My build farm member (corgi) did pass all checks 6 days ago (I was having some issues with the build farm code before that). If

Re: [HACKERS] Fw: Is anyone interested in getting PostgreSQL working

2006-01-09 Thread Stefan Kaltenbrunner
Jim Buttafuoco wrote: Stefan, first i would ask you to fix your mailserver setup because my last Mail to you bounced with: 550 5.0.0 Sorry we don't accept mail from Austria which makes it rather difficult for me to reply to your personal mail well that is good news, can you tell me what

[HACKERS] problem with large maintenance_work_mem settings and CREATE INDEX

2006-03-04 Thread Stefan Kaltenbrunner
Hi all! while playing on a new box i noticed that postgresql does not seem to be able to cope with very large settings for maintenance_work_mem. For a test I created a single table with 5 integer columns containing about 1,8B rows 8(about 300M distinct values in the column I want to index):

Re: [HACKERS] problem with large maintenance_work_mem settings and

2006-03-04 Thread Stefan Kaltenbrunner
Stefan Kaltenbrunner wrote: Hi all! while playing on a new box i noticed that postgresql does not seem to be able to cope with very large settings for maintenance_work_mem. For a test I created a single table with 5 integer columns containing about 1,8B rows 8(about 300M distinct values

Re: [HACKERS] problem with large maintenance_work_mem settings and

2006-03-04 Thread Stefan Kaltenbrunner
hubert depesz lubaczewski wrote: On 3/4/06, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote: forgot to mention that this is 8.1.3 compiled from source. Further testing shows that not only CREATE INDEX has some issue with large maintenance_work_mem settings : what does it show: cat /proc/sys

Re: [HACKERS] problem with large maintenance_work_mem settings and

2006-03-04 Thread Stefan Kaltenbrunner
Stefan Kaltenbrunner wrote: hubert depesz lubaczewski wrote: On 3/4/06, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote: forgot to mention that this is 8.1.3 compiled from source. Further testing shows that not only CREATE INDEX has some issue with large maintenance_work_mem settings : what

Re: [HACKERS] problem with large maintenance_work_mem settings and

2006-03-04 Thread Stefan Kaltenbrunner
Michael Paesold wrote: Stefan Kaltenbrunner wrote: hubert depesz lubaczewski wrote: On 3/4/06, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote: forgot to mention that this is 8.1.3 compiled from source. Further testing shows that not only CREATE INDEX has some issue with large

Re: [HACKERS] problem with large maintenance_work_mem settings and

2006-03-04 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: not that I think it is related to the problem at all. It looks like I'm hitting the MaxAllocSize Limit in src/include/utils/memutils.h. just tried to increase this limit to 4GB (from the default 1GB) and this seems to help

[HACKERS] EXPLAIN and HashAggregate

2006-03-04 Thread Stefan Kaltenbrunner
While playing around with large work_mem(or in that case a bit insane) and maintenance_work_mem settings I noticed that EXPLAIN behaves quite weird: foo=# set work_mem to 20; SET Time: 0.187 ms foo=# explain select count(*) from testtable2 group by a; QUERY

Re: [HACKERS] problem with large maintenance_work_mem settings and

2006-03-05 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: forgot to mention that this is 8.1.3 compiled from source. See the discussion starting here: http://archives.postgresql.org/pgsql-hackers/2006-02/msg00590.php I was following this thread - and it was partly a reason why I'm

Re: [HACKERS] problem with large maintenance_work_mem settings and

2006-03-08 Thread Stefan Kaltenbrunner
Tom Lane wrote: I wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: samples %symbol name 24915704 96.2170 ltsReleaseBlock We probably need to tweak things so this doesn't get called during the final merge pass. Looking at it now. I've committed a fix for this into CVS

Re: [HACKERS] problem with large maintenance_work_mem settings and

2006-03-08 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: CREATE INDEX on a 1,8B row table (5 int columns - index created on the first row about 300M distinct values): before: 11h 51min after: 3h 11min(!) Cool. Does it seem to be I/O bound now? Would you be willing to do

Re: [HACKERS] problem with large maintenance_work_mem settings and

2006-03-09 Thread Stefan Kaltenbrunner
Simon Riggs wrote: On Wed, 2006-03-08 at 10:45 -0500, Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: CREATE INDEX on a 1,8B row table (5 int columns - index created on the first row about 300M distinct values): before: 11h 51min after: 3h 11min(!) Cool. Does it seem

Re: [HACKERS] problem with large maintenance_work_mem settings and

2006-03-09 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: samples %symbol name 103520432 47.9018 inlineApplySortFunction 33382738 15.4471 comparetup_index 25296438 11.7054 tuplesort_heap_siftup 10089122 4.6685 btint4cmp 8395676 3.8849 LogicalTapeRead 2873556 1.3297

Re: [HACKERS] problem with large maintenance_work_mem settings and

2006-03-10 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: LOG: begin index sort: unique = f, workMem = 8024000, randomAccess = f LOG: switching to external sort with 28658 tapes: CPU 4.18s/13.96u sec elapsed 32.43 sec LOG: finished writing run 1 to tape 0: CPU 173.56s/3425.85u sec

[HACKERS] random observations while testing with a 1,8B row table

2006-03-10 Thread Stefan Kaltenbrunner
Hi all! During my testing of large work_mem and maintainence_work_mem setting wrt to CREATE INDEX and sorting I encountered a number of things wrt to doing various operations on such a large table (about 106GB on disk with no dead tuples). I will summarize some of the just in case somebody is

Re: [HACKERS] random observations while testing with a 1,8B row table

2006-03-10 Thread Stefan Kaltenbrunner
Luke Lonergan wrote: Stefan, On 3/10/06 9:40 AM, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote: I will summarize some of the just in case somebody is interested: I am! heh - not surprised :-) - table used has 5 integer columns non-indexed during the loads - hardware is a Dual

Re: [HACKERS] random observations while testing with a 1,8B row table

2006-03-10 Thread Stefan Kaltenbrunner
Luke Lonergan wrote: Stefan, On 3/10/06 11:48 AM, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote: 2 HBAs in the server, 2x2 possible paths to each LUN. 6 disks for the WAL and 12 disks for the data So - you have 18 disks worth of potential bandwidth, not factoring loss due to RAID

Re: [HACKERS] random observations while testing with a 1,8B row table

2006-03-11 Thread Stefan Kaltenbrunner
Luke Lonergan wrote: Stefan, On 3/10/06 12:23 PM, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote: wrong(or rather extremely optimistic) the array itself only has two (redundant) FC-loops(@2GB )to the attached expansion chassis. The array has 2 active/active controllers (with a failover

Re: [HACKERS] random observations while testing with a 1,8B row table

2006-03-11 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: 3. vacuuming this table - it turned out that VACUUM FULL is completly unusable on a table(which i actually expected before) of this size not only to the locking involved but rather due to a gigantic memory requirement

Re: [HACKERS] problem with large maintenance_work_mem settings and

2006-03-11 Thread Stefan Kaltenbrunner
Tom Lane wrote: I wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: samples %symbol name 350318533 98.8618 mergepreread 9718220.2743 tuplesort_gettuple_common 4136740.1167 tuplesort_heap_siftup I don't have enough memory to really reproduce this, but I've come close

[HACKERS] ERROR: record type has not been registered on CVS head

2006-03-12 Thread Stefan Kaltenbrunner
While trying to help somebody on IRC with slow queries against information_schema i stumbled across the following EXPLAIN buglet (much reduced from the original one and does not make a lot of sense therefore): foo=# explain SELECT * FROM information_schema.constraint_column_usage JOIN

Re: [HACKERS] problems compiling CVS HEAD - LDAP auth and Kerberos

2006-03-16 Thread Stefan Kaltenbrunner
Tom Lane wrote: Albe Laurenz [EMAIL PROTECTED] writes: Compiling src/interfaces/libpq/fe-auth.c on Linux I get gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -fno-strict-aliasing -I../../../src/include -D_GNU_SOURCE -I/usr/kerberos/include -c -o

Re: [HACKERS] Number of dimensions of an array parameter

2006-05-08 Thread Stefan Kaltenbrunner
Thomas Hallgren wrote: I can create a function that takes a two dimension int array: CREATE FUNCTION twodims(int[][]) RETURNS void AS ... but there's nothing stopping me from calling this function with an arbitrary number of dimensions on the array. I'd like to map a parameter like the

[HACKERS] hashagg, statistisics and excessive memory allocation

2006-05-11 Thread Stefan Kaltenbrunner
Hi! on irc somebody complained yesterday that a simple group by on a 25M integer row caused his backend to exhaust the 3GB process limit on his 32bit built(one a box with 16GB Ram). Some testing showed that the planner was seriously underestimating the number of distinct rows in the table (with

Re: [HACKERS] Going for all green buildfarm results

2006-06-02 Thread Stefan Kaltenbrunner
Tom Lane wrote: I've been making another pass over getting rid of buildfarm failures. The remaining ones I see at the moment are: firefly HEAD: intermittent failures in the stats test. We seem to have fixed every other platform back in January, but not this one. kudu HEAD: one-time

Re: [HACKERS] COPY (query) TO file

2006-06-02 Thread Stefan Kaltenbrunner
Andrew Dunstan wrote: Mark Woodward wrote: Tom had posted a question about file compression with copy. I thought about it, and I want to through this out and see if anyone things it is a good idea. Currently, the COPY command only copies a table, what if it could operate with a query, as:

Re: [HACKERS] Going for all green buildfarm results

2006-06-02 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: FWIW: lionfish had a weird make check error 3 weeks ago which I (unsuccessfully) tried to reproduce multiple times after that: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfishdt=2006-05-12%2005:30:14 Weird

Re: [HACKERS] bison version

2006-06-10 Thread Stefan Kaltenbrunner
ohp@pyrenet.fr wrote: Hi, I'd like to check 2 things: What's the bison version required to compile gram.y ? Trying to set up a build farm machine, it seems I can't compile with bison 2.1 ... 2.1 should work fine - there are a number of boxes on the buildfarm running with that version

Re: [HACKERS] emu buildfarm failure

2006-06-15 Thread Stefan Kaltenbrunner
Tom Lane wrote: Buildfarm member emu is failing in some branches with checking libintl.h usability... yes checking libintl.h presence... no configure: WARNING: libintl.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: libintl.h: proceeding with the

Re: [HACKERS] Test request for Stats collector performance improvement

2006-06-15 Thread Stefan Kaltenbrunner
Bruce Momjian wrote: Would some people please run the attached test procedure and report back the results? I basically need to know the patch is an improvement on more platforms than just my own. Thanks OpenBSD 3.9-current/x86: without stats: 0m6.79s real 0m1.56s user 0m1.12s

Re: [HACKERS] Test request for Stats collector performance improvement

2006-06-15 Thread Stefan Kaltenbrunner
Bruce Momjian wrote: Would some people please run the attached test procedure and report back the results? I basically need to know the patch is an improvement on more platforms than just my own. Thanks Debian Sarge/AMD64 Kernel 2.6.16.16 (all tests done multiple times with variation of

Re: [HACKERS] Test request for Stats collector performance improvement

2006-06-16 Thread Stefan Kaltenbrunner
Bruce Momjian wrote: OK, based on reports I have seen, generally stats_query_string adds 50% to the total runtime of a SELECT 1 query, and the patch reduces the overhead to 25%. that is actually not true for both of the platforms(a slow OpenBSD 3.9/x86 and a very fast Linux/x86_64) I tested

Re: [HACKERS] Test request for Stats collector performance improvement

2006-06-16 Thread Stefan Kaltenbrunner
Bruce Momjian wrote: Stefan Kaltenbrunner wrote: Bruce Momjian wrote: OK, based on reports I have seen, generally stats_query_string adds 50% to the total runtime of a SELECT 1 query, and the patch reduces the overhead to 25%. that is actually not true for both of the platforms(a slow

Re: [HACKERS] regresssion script hole

2006-06-19 Thread Stefan Kaltenbrunner
Michael Fuhr wrote: On Sun, Jun 18, 2006 at 07:18:07PM -0600, Michael Fuhr wrote: Maybe I'm misreading the packet, but I think the query is for ''kaltenbrunner.cc (two single quotes followed by kaltenbrunner.cc) Correction: ''.kaltenbrunner.cc yes that is exactly the issue - the postmaster

Re: [HACKERS] regresssion script hole

2006-06-19 Thread Stefan Kaltenbrunner
Andrew Dunstan wrote: Tom Lane wrote: Anyway, the tail end of the trace shows it repeatedly sending off a UDP packet and getting practically the same data back: I'm not too up on what the DNS protocol looks like on-the-wire, but I'll bet this is it. I think it's trying to look up

Re: [HACKERS] regresssion script hole

2006-06-19 Thread Stefan Kaltenbrunner
Martijn van Oosterhout wrote: On Mon, Jun 19, 2006 at 09:21:21AM -0400, Tom Lane wrote: Of course the $64 question is *why* is 8.0 trying to resolve that name, particularly seeing that the later branches apparently aren't. The formatting of the message suggests it is a gethostbyname('')

Re: [HACKERS] regresssion script hole

2006-06-19 Thread Stefan Kaltenbrunner
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: The question isn't whether is succeeds, it's how long it takes to succeed. When I increased the pg_regress timeout it actually went through the whole regression test happily. I suspect we have 2 things eating up the 60s timeout here:

Re: [HACKERS] [CORE] GPL Source and Copyright Questions

2006-06-22 Thread Stefan Kaltenbrunner
Tom Lane wrote: Josh Berkus josh@agliodbs.com writes: Yeah, thanks for reminding me. Will do before feature freeze. As soon as I can figure out how to generate a patch that removes directories. Don't worry about that; CVS never deletes directories. But anyway, I can easily handle

Re: [HACKERS] Overhead for stats_command_string et al, take 2

2006-06-22 Thread Stefan Kaltenbrunner
Tom Lane wrote: The bad news is that except in the stats_command_string cases, HEAD is noticeably slower than 8.1 on the machine with slow gettimeofday. In the single-transaction test this might be blamed on the addition of statement_timestamp support (which requires a gettimeofday per

Re: [HACKERS] Overhead for stats_command_string et al, take 2

2006-06-22 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: This is what I get on a fast AMD Dual Opteron box(Running Debian Sarge/AMD64): 8.1.4 HEAD 100 SELECT 1;74,74,7377,76,77 stats_command_string=1

Re: [HACKERS] Overhead for stats_command_string et al, take 2

2006-06-22 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Tom Lane wrote: Or do you mean that you have stats_row_level and/or stats_block_level on in all four cases? yes - stats_row_level and stats_block_level on in all cases (sorry for the confusion) - I can easily redo the tests

Re: [HACKERS] vacuum, performance, and MVCC

2006-06-23 Thread Stefan Kaltenbrunner
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I think at some point we have to admit that _polling_ the tables, which is what autovacuum does, just isn't going to work well, no matter how much it is tweeked, and another approach should be considered for certain workload cases.

[HACKERS] GIN index creation extremely slow ?

2006-06-26 Thread Stefan Kaltenbrunner
on IRC somebody mentioned that it took 34h to greate a GIN index (on a tsvector) on a ~3 Million column table (wikipedia dump) with a reasonable speced box (AMD 3400+). After getting hold of a dump of said table (around 4,1GB in size) I managed to get the following timings: test=# CREATE INDEX

Re: [HACKERS] GIN index creation extremely slow ?

2006-06-27 Thread Stefan Kaltenbrunner
Teodor Sigaev wrote: test=# CREATE INDEX idxFTI_idx ON wikipedia USING gist(vector); CREATE INDEX Time: 416122.896 ms so about 7 minutes - sounds very reasonable test=# CREATE INDEX idxFTI2_idx ON wikipedia USING gin(vector); CREATE INDEX Time: 52681605.101 ms I'll look at this, but

Re: [HACKERS] GIN index creation extremely slow ?

2006-06-30 Thread Stefan Kaltenbrunner
Teodor Sigaev wrote: Tom did commit a patch a while ago which made a huge difference in index creation time for tsearch by changing one routine. I don't know if it got backpatched, so it might be worth checking people are working on the same version. I saw that patch, but I still think that

Re: [HACKERS] Removing AddDepends; should I bother with a project?

2006-07-10 Thread Stefan Kaltenbrunner
Bruce Momjian wrote: Josh Berkus wrote: Folks, For the code sprint, I'm starting off by removing the projects from contrib which need to be removed by still have some usefulness. I'm not exactly sure what to do with adddepends, though. It seems unlike to lead an independent existence

Re: [HACKERS] contrib promotion?

2006-07-14 Thread Stefan Kaltenbrunner
Greg Sabino Mullane wrote: Doesn't our inclusion of md5() pretty much blow that argument away? (Just asking). I don't think so because md5 is just a one way hash function. There is no method to decrypt anything :). Actually, I've had to install pgcrypto on more than one occasion for

Re: [HACKERS] Windows buildfarm support, or lack of it

2006-07-16 Thread Stefan Kaltenbrunner
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Dave Page wrote: I can bump that up as high as you'd like within reason. 4? 6 times a day? Let's go for 6, at least for HEAD. There's probably no need to check the back branches oftener than once a day, but if you can do HEAD every

Re: CSStorm occurred again by postgreSQL8.2. (Re: [HACKERS] poor

2006-07-19 Thread Stefan Kaltenbrunner
Katsuhiko Okano wrote: Tom Lane [EMAIL PROTECTED] wrote: Katsuhiko Okano [EMAIL PROTECTED] writes: It does not solve, even if it increases the number of NUM_SUBTRANS_BUFFERS. The problem was only postponed. Can you provide a reproducible test case for this? Seven machines are required in

Re: [HACKERS] Adding a pgbench run to buildfarm

2006-07-24 Thread Stefan Kaltenbrunner
Mark Kirkwood wrote: Tom Lane wrote: Bort, Paul [EMAIL PROTECTED] writes: Andrew said I should solicit opinions as to what parameters to use. A cursory search through the archives led me to pick a scaling factor of 10, 5 users, and 100 transactions. 100 transactions seems barely enough to

Re: [HACKERS] [COMMITTERS] pgsql: /contrib/cube improvements: Update

2006-07-26 Thread Stefan Kaltenbrunner
Bruce Momjian wrote: Tom Lane wrote: Joshua Reich [EMAIL PROTECTED] writes: The problem is that there are new functions in cube.sql, so the output is now different and breaks the diff (to state the obvious). Actually, the new theory on this is that you should explicitly create a shell type

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Stefan Kaltenbrunner
Andrew Dunstan wrote: Can one of the Windows buildfarm owners please try building and running make check by hand rather than using the buildfarm script? It looks like they all stopped reporting around the same time, and this might give us a better clue about when things fall over. Also,

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Stefan Kaltenbrunner
Tom Lane wrote: I wrote: Andrew Dunstan [EMAIL PROTECTED] writes: The TimeZone changes are looking might suspicious ... FATAL: failed to initialize timezone_abbreviations to Default Hm. It looks like this is working in the postmaster but failing in subprocesses. I'll see if I can

Re: [HACKERS] [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

2006-07-28 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: I get a much more useful: WARNING: could not read time zone file Default: No such file or directory FATAL: failed to initialize timezone_abbreviations to Default Hm, but why would the file not be there? Try hacking

Re: [HACKERS] Going for all green buildfarm results

2006-07-29 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: FWIW: lionfish had a weird make check error 3 weeks ago which I (unsuccessfully) tried to reproduce multiple times after that: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfishdt=2006-05-12%2005:30:14 Weird

Re: [HACKERS] Going for all green buildfarm results

2006-07-30 Thread Stefan Kaltenbrunner
Alvaro Herrera wrote: Stefan Kaltenbrunner wrote: Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: FWIW: lionfish had a weird make check error 3 weeks ago which I (unsuccessfully) tried to reproduce multiple times after that: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm

Re: [HACKERS] Going for all green buildfarm results

2006-07-31 Thread Stefan Kaltenbrunner
Jim C. Nasby wrote: On Sun, Jul 30, 2006 at 11:44:44AM -0400, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Stefan Kaltenbrunner wrote: FYI: lionfish just managed to hit that problem again: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfishdt=2006-07-29%2023:30:06 The test

Re: [HACKERS] Going for all green buildfarm results

2006-07-31 Thread Stefan Kaltenbrunner
Andrew Dunstan wrote: Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Jim C. Nasby wrote: On Sun, Jul 30, 2006 at 11:44:44AM -0400, Tom Lane wrote: The path of least resistance might just be to not run these tests in parallel. The chance of this issue causing

Re: [HACKERS] 8.2 features status

2006-08-04 Thread Stefan Kaltenbrunner
Merlin Moncure wrote: On 8/3/06, Tom Lane [EMAIL PROTECTED] wrote: I'm not clear on why there's all this doom and gloom about how 8.2 will be merely a performance-oriented release, with few new features, eg http://archives.postgresql.org/pgsql-hackers/2006-07/msg00111.php Certainly there's

Re: [HACKERS] buildfarm - make check failures for leveret on 8.0

2006-08-07 Thread Stefan Kaltenbrunner
Jeremy Drake wrote: On Mon, 7 Aug 2006, Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: *) why the large difference in the build-flags ? CVS HEAD configure.in knows about icc and the release branches don't. I think the changes were only put into HEAD because of lack

Re: [HACKERS] buildfarm - make check failures for leveret on 8.0

2006-08-08 Thread Stefan Kaltenbrunner
Tom Lane wrote: Jeremy Drake [EMAIL PROTECTED] writes: Plus if it is backported, I can enable 8.x builds on mongoose (my x86 icc buildfarm box). Please do --- I've applied the changes in 8.1 and 8.0 branches. and leveret went green on both 8.0 and 8.1 ... Stefan

Re: [HACKERS] buildfarm - make check failures for leveret on 8.0

2006-08-08 Thread Stefan Kaltenbrunner
Andrew Dunstan wrote: Stefan Kaltenbrunner wrote: Tom Lane wrote: Jeremy Drake [EMAIL PROTECTED] writes: Plus if it is backported, I can enable 8.x builds on mongoose (my x86 icc buildfarm box). Please do --- I've applied the changes in 8.1 and 8.0 branches

  1   2   3   4   5   6   7   8   >