[PATCHES] default database creation with initdb

2005-06-18 Thread Andreas Pflug
As per discussion on -hackers the attached patch creates the 'default' database at initdb time as a default target for initial connections to keep template1 free from connections and available as template source. I consider this DB a system object, so it's created before make_template0 sets

Re: [PATCHES] default database creation with initdb

2005-06-18 Thread Magnus Hagander
Umm. Tiny item, but your comment still refers to the database as pg_system ;-) //Magnus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Pflug Sent: Saturday, June 18, 2005 10:42 AM To: PostgreSQL-patches Subject: [PATCHES] default

Re: [PATCHES] default database creation with initdb

2005-06-18 Thread Andreas Pflug
Magnus Hagander wrote: Umm. Tiny item, but your comment still refers to the database as pg_system ;-) :-) Regards, Andreas Index: src/bin/initdb/initdb.c === RCS file: /projects/cvsroot/pgsql/src/bin/initdb/initdb.c,v retrieving

Re: [PATCHES] default database creation with initdb

2005-06-18 Thread Tom Lane
Andreas Pflug [EMAIL PROTECTED] writes: + CREATE DATABASE \default\;\n, + REVOKE CREATE,TEMPORARY ON DATABASE \default\ FROM public;\n, Uh, why the rights revocation? That makes the thing essentially useless ... except to superusers, who will not be affected anyway.

Re: [PATCHES] default database creation with initdb

2005-06-18 Thread Bruno Wolff III
On Sat, Jun 18, 2005 at 09:27:49 -0400, Robert Treat [EMAIL PROTECTED] wrote: On Saturday 18 June 2005 04:55, Andreas Pflug wrote: Magnus Hagander wrote: Umm. Tiny item, but your comment still refers to the database as pg_system ;-) What is the purpose of this database? A

Re: [PATCHES] TODO Item - Return compressed length of TOAST datatypes (WIP)

2005-06-18 Thread Tom Lane
Mark Kirkwood [EMAIL PROTECTED] writes: I thought I would have a look at: (Datatypes) Add function to return compressed length of TOAST data values. My recollection of that discussion is that we just wanted something that would return the actual VARSIZE() of the datum. You're building

Re: [PATCHES] Post-mortem: final 2PC patch

2005-06-18 Thread Stefan Kaltenbrunner
Tom Lane wrote: I've attached the 2PC patch as applied in case you want to have a look. I did some fairly significant hacking on it, and I thought it'd be a good idea to enumerate some of the changes: FYI: this commit seems to cause problems/crashes during make check on my OpenBSD/Sparc64

Re: [PATCHES] Post-mortem: final 2PC patch

2005-06-18 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: FYI: this commit seems to cause problems/crashes during make check on my OpenBSD/Sparc64 buildfarmclient: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbilldt=2005-06-17%2023:50:04 I just checked manually with a fresh checkout - and I

Re: [PATCHES] Post-mortem: final 2PC patch

2005-06-18 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: FYI: this commit seems to cause problems/crashes during make check on my OpenBSD/Sparc64 buildfarmclient: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbilldt=2005-06-17%2023:50:04 I just checked manually with a

Re: [PATCHES] Post-mortem: final 2PC patch

2005-06-18 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Can you get a stack trace from the core dump? (gdb) bt #0 0x50377ba4 in memcpy () from /usr/lib/libc.so.34.2 #1 0x00326efc in hash_search () #2 0x00343430 in pg_tzset () #3 0x001fbcf0 in assign_timezone ()

Re: [PATCHES] Post-mortem: final 2PC patch

2005-06-18 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Can you get a stack trace from the core dump? (gdb) bt #0 0x50377ba4 in memcpy () from /usr/lib/libc.so.34.2 #1 0x00326efc in hash_search () #2 0x00343430 in pg_tzset () #3 0x001fbcf0 in

Re: [PATCHES] Post-mortem: final 2PC patch

2005-06-18 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: the machine had some issues a week ago or so - but it looks like the problem occured first here: Hmm, what kind of issues, and are you sure they are fixed? The stack trace looks to me like it is trying to apply the PGTZ setting that's coming in

Re: [PATCHES] Post-mortem: final 2PC patch

2005-06-18 Thread Stefan Kaltenbrunner
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: the machine had some issues a week ago or so - but it looks like the problem occured first here: Hmm, what kind of issues, and are you sure they are fixed? admin error :-). I had a second postgresql instance running causing

Re: [PATCHES] Post-mortem: final 2PC patch

2005-06-18 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: anyway - here is the promised backtrace: #0 0x4489fba4 in memcpy () from /usr/lib/libc.so.34.2 #1 0x00326f9c in hash_search (hashp=0xa6e030, keyPtr=0xa5ff90, action=HASH_ENTER, foundPtr=0x0) at dynahash.c:653 #2

[PATCHES] Typo in pl_funcs.c comment

2005-06-18 Thread Michael Fuhr
pl_funcs.c has a comment that refers to functins, which I'm assuming should be functions. The attached patch corrects the spelling. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ Index: src/pl/plpgsql/src/pl_funcs.c === RCS file:

Re: [PATCHES] Post-mortem: final 2PC patch

2005-06-18 Thread Heikki Linnakangas
On Sat, 18 Jun 2005, Tom Lane wrote: I've attached the 2PC patch as applied in case you want to have a look. I did some fairly significant hacking on it, and I thought it'd be a good idea to enumerate some of the changes: I modified the in-memory data structure so that there is a separate

Re: [PATCHES] Post-mortem: final 2PC patch

2005-06-18 Thread Tom Lane
Heikki Linnakangas [EMAIL PROTECTED] writes: On Sat, 18 Jun 2005, Tom Lane wrote: I'm not totally satisfied with this --- it's OK from a correctness standpoint but the performance leaves something to be desired. Ouch, that really hurts performance. In typical 2PC use, the state files live

Re: [PATCHES] Post-mortem: final 2PC patch

2005-06-18 Thread Heikki Linnakangas
On Sat, 18 Jun 2005, Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Can we figure out another way to solve the race condition? Would it in fact be ok for the checkpointer to hold the TwoPhaseStateLock, considering that it usually wouldn't be held for long, since usually the

Re: [PATCHES] Post-mortem: final 2PC patch

2005-06-18 Thread Tom Lane
Heikki Linnakangas [EMAIL PROTECTED] writes: In step 3.1, is it safe to skip gxacts not marked as valid? The gxact is marked as valid after the prepare record is written to WAL. If checkpoint runs after the WAL record is written but before the gxact is marked as valid, it doesn't get

Re: [PATCHES] TODO Item - Return compressed length of TOAST datatypes

2005-06-18 Thread Mark Kirkwood
Tom Lane wrote: Mark Kirkwood [EMAIL PROTECTED] writes: I thought I would have a look at: (Datatypes) Add function to return compressed length of TOAST data values. My recollection of that discussion is that we just wanted something that would return the actual VARSIZE() of the datum.

Re: [PATCHES] Typo in pl_funcs.c comment

2005-06-18 Thread Bruce Momjian
Thanks, applied. --- Michael Fuhr wrote: pl_funcs.c has a comment that refers to functins, which I'm assuming should be functions. The attached patch corrects the spelling. -- Michael Fuhr

[PATCHES] Python setof patch

2005-06-18 Thread Gerrit van Dyk
Hi, This patch allows the PL/Python module to do (SRF) functions. The patch was taken from the CVS version. I have modified the plpython.c file and have added a test sql script for testing the functionality. It was actually the script that was in the 8.0.3 version but have since been

Re: [PATCHES] Add PG version number to NLS files

2005-06-18 Thread Martin Pitt
Hi! Bruce Momjian [2005-06-15 15:26 -0400]: Peter Eisentraut wrote: Bruce Momjian wrote: The 'bind' calles in the binaries are going to look for the proper version. Does that help, or is libpq the only thing we need to handle? Shared libraries have their version number embedded