Re: [HACKERS] RC1?
Patrick Welche wrote: On Tue, Nov 19, 2002 at 06:22:08PM +0100, Peter Eisentraut wrote: He was testing 7.4devel. That's not the right one. What's the difference? (Do I really want to wait another day while this ancient box compiles it given that the chances of it working under 7.4devel and not under 7.3rcN are smaller than the chances of it working under 7.3rcN and not under 7.4devel, no?) Uh, you are right, but we have made a _few_ 7.4 changes so I do think we need a 7.3-specific test. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] float4 problem
May be I miss something, but seems there is a problem with float4 in 7.2.3 and 7.3RC1 (6.53 works fine): test=# create table t ( a float4); CREATE TABLE test=# insert into t values (0.1); INSERT 32789 1 test=# select * from t where a=0.1; a --- (0 rows) test=# select * from t where a=0.1::float4; a - 0.1 (1 row) No problem with float8 test=# create table t8 ( a float8); CREATE TABLE test=# insert into t8 values (0.1); INSERT 32792 1 test=# select * from t8 where a=0.1; a - 0.1 (1 row) Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Geometry test on NetBSD (was Re: [HACKERS] RC1?)
Bruce Momjian [EMAIL PROTECTED] wrote: Tom, can you clarify why -0 is valid. Is it for _small_ near zero values that are indeed negative? Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit W. Kahan; ch. 7 in _The State of the Art in Numerical Analysis_ ed. by M. Powell and A. Iserles 1987 Oxford. Explains how proper respect for -0 eases implementation of conformal maps of slitted domains arising in studies of flows around obstacles. Kahan was one of the most important people behind the floating point standard and won the 1989 Turing Award for his work in numerical computing. http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] float4 problem
Oleg Bartunov [EMAIL PROTECTED] writes: May be I miss something, but seems there is a problem with float4 in 7.2.3 and 7.3RC1 (6.53 works fine): test=# create table t ( a float4); CREATE TABLE test=# insert into t values (0.1); INSERT 32789 1 test=# select * from t where a=0.1; a --- (0 rows) I'm guessing this is because 0.1 is not directly representable as a binary floating point number, and literal floating constants are float8 not float4, and 0.1::float4 != 0.1::float8. Same problem that causes queries on int2 fields not to use an index unless you cast the constants in the query... -Doug ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
Tom Lane writes: AFAIK, all modern hardware claims compliance to the IEEE floating-point arithmetic standard, so failure to print minus zero as minus zero is very likely to be a software issue not hardware. That suggests strongly that the issue is netbsd version (specifically libc version) and not the hardware platform. I could confirm my initial suspicion: it's a *printf() library issue. The FreeBSD CVS log tells the tale: http://www.de.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/vfprintf.c The next FreeBSD subrelease (4.8?) should have this fixed. OpenBSD is not fixed. NetBSD and Darwin seem to have temporarily hidden their cvsweb in shame, but I would assume it's the same issue. Not sure what HP-UX is doing about it. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Fw: Missing file from CVS?
Heres a patch which will create the sql_help.h file if it doesn't already exist using an installed copy of perl. I've tested it using perl v5.6.1 from ActiveState and all appears to work. Can someone commit this for me, or throw back some comments. Thanks, Al. --- src/bin/psql/win32.mak 2002/10/29 04:23:30 1.11 +++ src/bin/psql/win32.mak 2002/11/20 19:44:35 @@ -7,14 +7,16 @@ !ENDIF CPP=cl.exe +PERL=perl.exe OUTDIR=.\Release INTDIR=.\Release +REFDOCDIR= ../../../doc/src/sgml/ref # Begin Custom Macros OutDir=.\Release # End Custom Macros -ALL : $(OUTDIR)\psql.exe +ALL : sql_help.h $(OUTDIR)\psql.exe CLEAN : -@erase $(INTDIR)\command.obj @@ -91,3 +93,7 @@ $(CPP) @ $(CPP_PROJ) $ + +sql_help.h: create_help.pl +$(PERL) create_help.pl $(REFDOCDIR) $@ + - Original Message - From: Al Sutton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 15, 2002 8:48 PM Subject: Missing file from CVS? All, I've just tried to build the Win32 components under Visual Studio's C++ compiler from the win32.mak CVS archive at :pserver:[EMAIL PROTECTED]:/projects/cvsroot and found that the following file was missing; src\bin\psql\sql_help.h I've copied the file from the the source tree of version 7.2.3 and the compile works with out any problems. Should the file be in CVS? Al. ---(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] float4 problem
Doug McNaught [EMAIL PROTECTED] writes: Oleg Bartunov [EMAIL PROTECTED] writes: May be I miss something, but seems there is a problem with float4 in 7.2.3 and 7.3RC1 (6.53 works fine): test=# create table t ( a float4); CREATE TABLE test=# insert into t values (0.1); INSERT 32789 1 test=# select * from t where a=0.1; a --- (0 rows) I'm guessing this is because 0.1 is not directly representable as a binary floating point number, and literal floating constants are float8 not float4, and 0.1::float4 != 0.1::float8. Right. I think that this particular form of the problem will go away in 7.4. Currently, a = 0.1 is resolved as float4=float8, and there's no way for the float4 approximation of 0.1 to exactly equal the float8 approximation of it. However, if we eliminate cross-datatype comparison operators as I've proposed, the comparison should be resolved as float4 = float4 and it would work. Nonetheless, expecting exact equality tests to succeed with float values is generally folly. I really do not believe the claim that this worked in 6.5.3. 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: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
On Wed, Nov 20, 2002 at 06:48:15PM +0100, Peter Eisentraut wrote: Tom Lane writes: AFAIK, all modern hardware claims compliance to the IEEE floating-point arithmetic standard, so failure to print minus zero as minus zero is very likely to be a software issue not hardware. That suggests strongly that the issue is netbsd version (specifically libc version) and not the hardware platform. I could confirm my initial suspicion: it's a *printf() library issue. The FreeBSD CVS log tells the tale: http://www.de.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/vfprintf.c The next FreeBSD subrelease (4.8?) should have this fixed. OpenBSD is not fixed. NetBSD and Darwin seem to have temporarily hidden their cvsweb in shame, but I would assume it's the same issue. Not sure what HP-UX is doing about it. Right, the equivalent for NetBSD vfprintf.c is: revision 1.40 date: 2001/11/28 11:58:22; author: kleink; state: Exp; lines: +4 -4 Since we're returned the sign of a floating-point number by __dtoa(), use that to decide whether to include a minus sign in the result. Fixes printing -0.0, and thus PR lib/3137. NetBSD 1.5 has revision 1.32, NetBSD 1.6 has revision 1.42 Well spotted, Patrick ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
Patrick Welche [EMAIL PROTECTED] writes: Right, the equivalent for NetBSD vfprintf.c is: revision 1.40 date: 2001/11/28 11:58:22; author: kleink; state: Exp; lines: +4 -4 Since we're returned the sign of a floating-point number by __dtoa(), use that to decide whether to include a minus sign in the result. Fixes printing -0.0, and thus PR lib/3137. NetBSD 1.5 has revision 1.32, NetBSD 1.6 has revision 1.42 Ah-hah, so it is a version issue --- we could make the resultmap line something like geometry/.*-netbsd1.[0-5]=geometry-positive-zeros Would you confirm what config.guess prints on your box --- in particular, is there a dot in the version number? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
Peter Eisentraut [EMAIL PROTECTED] writes: The next FreeBSD subrelease (4.8?) should have this fixed. OpenBSD is not fixed. NetBSD and Darwin seem to have temporarily hidden their cvsweb in shame, but I would assume it's the same issue. Not sure what HP-UX is doing about it. HP has evidently fixed it in HPUX 11. I do not think they intend to change the behavior of HPUX 10 anymore, so the existing resultmap entries for geometry/hppa seem okay. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: ... NetBSD 1.5 has revision 1.32, NetBSD 1.6 has revision 1.42 Ah-hah, so it is a version issue --- we could make the resultmap line something like geometry/.*-netbsd1.[0-5]=geometry-positive-zeros Would you confirm what config.guess prints on your box --- in particular, is there a dot in the version number? Yes: NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1) NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1) (several NetBSDs probably come up with arm-unknown..) Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
Patrick Welche [EMAIL PROTECTED] writes: On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote: Ah-hah, so it is a version issue --- we could make the resultmap line something like geometry/.*-netbsd1.[0-5]=geometry-positive-zeros NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1) NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1) Hm, is that elf always there? I'm a little uncomfortable with making the pattern be geometry/.*-netbsd.*1.[0-5]=geometry-positive-zeros as this seems way too lax ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
On Wed, Nov 20, 2002 at 01:51:28PM -0500, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote: Ah-hah, so it is a version issue --- we could make the resultmap line something like geometry/.*-netbsd1.[0-5]=geometry-positive-zeros NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1) NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1) Hm, is that elf always there? I'm a little uncomfortable with making the pattern be geometry/.*-netbsd.*1.[0-5]=geometry-positive-zeros as this seems way too lax ... elf won't always be there - that acorn32 is a case in point: it became elf for 1.6. acorn26 has always been elf. I can't remember when i386 became elf.. (In fact the old config.guess that comes with NeTraMet44b8 says i386-unknown-netbsd1.6K - so maybe the config.guess cvs log may shed some light) Just realised: the answers I gave above were with the config.guess from automake 1.7a! % uname -srmp NetBSD 1.6K acorn32 arm % postgresql-7.3rc1/config/config.guess acorn32-unknown-netbsd1.6K % automake/lib/config.guess arm-unknown-netbsdelf1.6K Confusing.. Patrick ---(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: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
Patrick Welche [EMAIL PROTECTED] writes: Just realised: the answers I gave above were with the config.guess from automake 1.7a! % uname -srmp NetBSD 1.6K acorn32 arm % postgresql-7.3rc1/config/config.guess acorn32-unknown-netbsd1.6K % automake/lib/config.guess arm-unknown-netbsdelf1.6K Mph. Okay, I guess we'd better expend two patterns on this: geometry/.*-netbsd1.[0-5]=geometry-positive-zeros geometry/.*-netbsdelf1.[0-5]=geometry-positive-zeros Will make it so. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RC1?
On Wed, Nov 20, 2002 at 09:33:41AM -0500, Bruce Momjian wrote: Patrick Welche wrote: On Tue, Nov 19, 2002 at 06:22:08PM +0100, Peter Eisentraut wrote: He was testing 7.4devel. That's not the right one. What's the difference? (Do I really want to wait another day while this ancient box compiles it given that the chances of it working under 7.4devel and not under 7.3rcN are smaller than the chances of it working under 7.3rcN and not under 7.4devel, no?) Uh, you are right, but we have made a _few_ 7.4 changes so I do think we need a 7.3-specific test. OK - did 7.3rc1 successfully on NetBSD-1.6K/acorn32 and NetBSD-16H/i386 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RC1?
Ports list updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html --- Patrick Welche wrote: On Wed, Nov 20, 2002 at 09:33:41AM -0500, Bruce Momjian wrote: Patrick Welche wrote: On Tue, Nov 19, 2002 at 06:22:08PM +0100, Peter Eisentraut wrote: He was testing 7.4devel. That's not the right one. What's the difference? (Do I really want to wait another day while this ancient box compiles it given that the chances of it working under 7.4devel and not under 7.3rcN are smaller than the chances of it working under 7.3rcN and not under 7.4devel, no?) Uh, you are right, but we have made a _few_ 7.4 changes so I do think we need a 7.3-specific test. OK - did 7.3rc1 successfully on NetBSD-1.6K/acorn32 and NetBSD-16H/i386 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Bug with sequence
On Wed, 2002-11-20 at 21:35, Robert Treat wrote: On Wed, 2002-11-20 at 03:53, Oliver Elphick wrote: On Mon, 2002-11-18 at 15:45, Thomas Aichinger wrote: Hi, I recently installed pg 7.2.3 on my linux box and discovered that there are some problems with datatype serial and sequence. 1.) If you create a table with a datatype serial, the corrsponding sequence will be created, but if you drop the table the sequence is not dropped. This is fixed in 7.3 out of curiosity, do you know the logic that implements this fix? I have a couple of tables that use the same sequence; I'm wondering if dropping one of the tables removes the sequence or if I have to drop all tables before the sequence is removed I just tried it. I created a sequence using SERIAL when I created a table. I used the same sequence for another table by setting a column default to nextval(sequence). I deleted the first table. The sequence was deleted too, leaving the default of the second table referring to a non-existent sequence. Could this be a TODO item in 7.4, to add a dependency check when a sequence is set as the default without being created at the same time? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C If my people, which are called by my name, shall humble themselves, and pray, and seek my face, and turn from their wicked ways; then will I hear from heaven, and will forgive their sin, and will heal their land. II Chronicles 7:14 ---(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] [GENERAL] Bug with sequence
This requires changing the nextval() function to be an attribute of the sequence. ie. sequence.nextval and sequence.currval to deal with the sequence. It should also be on the todo list. On Wed, 2002-11-20 at 17:12, Oliver Elphick wrote: On Wed, 2002-11-20 at 21:35, Robert Treat wrote: On Wed, 2002-11-20 at 03:53, Oliver Elphick wrote: On Mon, 2002-11-18 at 15:45, Thomas Aichinger wrote: Hi, I recently installed pg 7.2.3 on my linux box and discovered that there are some problems with datatype serial and sequence. 1.) If you create a table with a datatype serial, the corrsponding sequence will be created, but if you drop the table the sequence is not dropped. This is fixed in 7.3 out of curiosity, do you know the logic that implements this fix? I have a couple of tables that use the same sequence; I'm wondering if dropping one of the tables removes the sequence or if I have to drop all tables before the sequence is removed I just tried it. I created a sequence using SERIAL when I created a table. I used the same sequence for another table by setting a column default to nextval(sequence). I deleted the first table. The sequence was deleted too, leaving the default of the second table referring to a non-existent sequence. Could this be a TODO item in 7.4, to add a dependency check when a sequence is set as the default without being created at the same time? -- Rod Taylor [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
Tom Lane wrote: Log message: Finish implementation of hashed aggregation. Add enable_hashagg GUC parameter to allow it to be forced off for comparison purposes. Add ORDER BY clauses to a bunch of regression test queries that will otherwise produce randomly-ordered output in the new regime. Tom, do we really want to add a GUC that is used just for comparison of performance? I know we have the seqscan on/off, but there are valid reasons to do that. Do you think there will be cases where it will faster to have this hash setting off? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Bug with sequence
Oliver Elphick wrote: On Wed, 2002-11-20 at 21:35, Robert Treat wrote: On Wed, 2002-11-20 at 03:53, Oliver Elphick wrote: On Mon, 2002-11-18 at 15:45, Thomas Aichinger wrote: Hi, I recently installed pg 7.2.3 on my linux box and discovered that there are some problems with datatype serial and sequence. 1.) If you create a table with a datatype serial, the corrsponding sequence will be created, but if you drop the table the sequence is not dropped. This is fixed in 7.3 out of curiosity, do you know the logic that implements this fix? I have a couple of tables that use the same sequence; I'm wondering if dropping one of the tables removes the sequence or if I have to drop all tables before the sequence is removed I just tried it. I created a sequence using SERIAL when I created a table. I used the same sequence for another table by setting a column default to nextval(sequence). I deleted the first table. The sequence was deleted too, leaving the default of the second table referring to a non-existent sequence. This sounds like a serious bug in our behaviour, and not something we'd like to release. Specifically in relation to people's existing scripts, and also to people who are doing dump/restore of specific tables (it'll kill the sequences that other tables depend on too!) No real issue with the nicety for newbies, but am very concerned about the lack of a dependancy check here. :-/ Regards and best wishes, Justin Clift Could this be a TODO item in 7.4, to add a dependency check when a sequence is set as the default without being created at the same time? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C If my people, which are called by my name, shall humble themselves, and pray, and seek my face, and turn from their wicked ways; then will I hear from heaven, and will forgive their sin, and will heal their land. II Chronicles 7:14 ---(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 -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(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] [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
Bruce Momjian [EMAIL PROTECTED] writes: Tom, do we really want to add a GUC that is used just for comparison of performance? I know we have the seqscan on/off, but there are valid reasons to do that. Do you think there will be cases where it will faster to have this hash setting off? Sure --- that's why the planner code is going to great lengths to try to choose the faster one. Even if I didn't think that, it'll be at least as useful as, say, enable_indexscan. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom, do we really want to add a GUC that is used just for comparison of performance? I know we have the seqscan on/off, but there are valid reasons to do that. Do you think there will be cases where it will faster to have this hash setting off? Sure --- that's why the planner code is going to great lengths to try to choose the faster one. Even if I didn't think that, it'll be at least as useful as, say, enable_indexscan. Oh, OK. Just checking. I was confused about your commit message because you seemed to be saying it was mostly for testing, and I thought you meant testing to see if the hash code is an improvement over what we had, rather than to see if the hash code is an improvement over the sequential scan GROUP BY path, which is still in the code. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] xBSD shmem doc deficiency
The documentation on changing shared memory kernel settings on xBSD (namely FreeBSD, possibly others as well) isn't ideal, IMHO. It says: %% The options SYSVSHM and SYSVSEM need to be enabled when the kernel is compiled. (They are by default.) The maximum size of shared memory is determined by the option SHMMAXPGS (in pages). The following shows an example of how to set the various parameters: options SYSVSHM options SHMMAXPGS=4096 options SHMSEG=256 options SYSVSEM options SEMMNI=256 options SEMMNS=512 options SEMMNU=256 options SEMMAP=256 (On NetBSD and OpenBSD the key word is actually option singular.) You may also want to use the sysctl setting to lock shared memory into RAM and prevent it from being paged out to swap. %% However, it appears that shared memory semaphore settings can also be controlled via sysctls -- at least on a FreeBSD 4.7-RELEASE box, I can see: kern.ipc.semmap: 30 kern.ipc.semmni: 10 kern.ipc.semmns: 60 kern.ipc.semmnu: 30 kern.ipc.semmsl: 60 kern.ipc.semopm: 100 kern.ipc.semume: 10 kern.ipc.semusz: 92 kern.ipc.semvmx: 32767 kern.ipc.semaem: 16384 kern.ipc.shmmax: 33554432 kern.ipc.shmmin: 1 kern.ipc.shmmni: 192 kern.ipc.shmseg: 128 kern.ipc.shmall: 8192 kern.ipc.shm_use_phys: 0 However, the FreeBSD box I'm playing with isn't mine, so I'm not too keen to change sysctls (well, that and I don't have root :-) ). Would a kind BSD user confirm that: (a) the sysctls above *can* be used to change kernel shared memory settings, and the default value of the sysctl is the kernel option referred to in the docs. (b) do the above sysctls work on NetBSD and OpenBSD as well? (c) the 'prevent shared memory paging' sysctl vaguely referred to in the docs is 'kern.ipc.shm_use_phys', right? (d) does the above sysctl also work on NetBSD and OpenBSD? Thanks in advance, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] xBSD shmem doc deficiency
On 20 Nov 2002, Neil Conway wrote: However, the FreeBSD box I'm playing with isn't mine, so I'm not too keen to change sysctls (well, that and I don't have root :-) ). Would a kind BSD user confirm that: (a) the sysctls above *can* be used to change kernel shared memory settings, and the default value of the sysctl is the kernel option referred to in the docs. (b) do the above sysctls work on NetBSD and OpenBSD as well? A quick look at OpenBSD 3.2 (man 3 sysctl) appears to show that all you can do at runtime is enable/disable message queues, shared memory, and semaphores, not adjust buffer counts or sizes. It seems the kernel must still be recompiled with the desired new settings. Jon ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] Bug with sequence
Justin Clift [EMAIL PROTECTED] writes: This sounds like a serious bug in our behaviour, and not something we'd like to release. It's not ideal, I agree, but I *definately* don't think this is grounds for changing the release schedule. No real issue with the nicety for newbies, but am very concerned about the lack of a dependancy check here. Well, how would you suggest we fix this? ISTM this is partially a result of the fact that we don't produce dependancy information for function bodies. While it might be possible to do so (in 7.4) for certain types of functions (e.g. for functions defined in SQL, PL/PgSQL, etc.), I can't see a general solution (e.g. for functions defined in C). And adding random hacks to get specific functions (e.g. nextval()) to work does not strike me as a very good idea. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] Bug with sequence
Neil Conway wrote: Justin Clift [EMAIL PROTECTED] writes: This sounds like a serious bug in our behaviour, and not something we'd like to release. It's not ideal, I agree, but I *definately* don't think this is grounds for changing the release schedule. Hey, I'm no fan of slowing the release schedule either. Bug this is definitely sounding like a bug. No real issue with the nicety for newbies, but am very concerned about the lack of a dependancy check here. Well, how would you suggest we fix this? ISTM this is partially a result of the fact that we don't produce dependancy information for function bodies. While it might be possible to do so (in 7.4) for certain types of functions (e.g. for functions defined in SQL, PL/PgSQL, etc.), I can't see a general solution (e.g. for functions defined in C). Absolutely *no* idea. And adding random hacks to get specific functions (e.g. nextval()) to work does not strike me as a very good idea. Agreed. Random hacks aren't always a good approach. Regards and best wishes, Justin Clift Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] Bug with sequence
Justin Clift [EMAIL PROTECTED] writes:
Oliver Elphick wrote:
I created a sequence using SERIAL when I created a table. I used the
same sequence for another table by setting a column default to
nextval(sequence).
I deleted the first table. The sequence was deleted too, leaving the
default of the second table referring to a non-existent sequence.
This sounds like a serious bug in our behaviour, and not something we'd
like to release.
We will be releasing it whether we like it or not, because
nextval('foo') doesn't expose any visible dependency on sequence foo.
(If you think it should, how about nextval('fo' || 'o')? If you think
that's improbable, consider nextval('table' || '_' || 'col' || '_seq').)
The long-term answer is to do what Rod alluded to: support the
Oracle-style syntax foo.nextval, so that the sequence reference is
honestly part of the parsetree and not buried inside a string
expression.
In the meantime, I consider that Oliver was misusing the SERIAL
feature. If you want multiple tables fed by the same sequence object,
you should create the sequence as a separate object and then create
the tables using explicit DEFAULT nextval('foo') clauses. Doing what
he did amounts to sticking his fingers under the hood of the SERIAL
implementation; if he gets his fingers burnt, it's his problem.
Specifically in relation to people's existing scripts, and also to
people who are doing dump/restore of specific tables (it'll kill the
sequences that other tables depend on too!)
7.3 breaks no existing schemas, because older schemas will be dumped
as separate CREATE SEQUENCE and CREATE TABLE ... DEFAULT nextval()
commands.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] xBSD shmem doc deficiency
Apparently only some settings are adjustable. root@dev:~# uname -smr FreeBSD 4.2-RELEASE i386 root@dev:~# sysctl -a | grep kern.ipc.semm kern.ipc.semmap: 30 kern.ipc.semmni: 10 kern.ipc.semmns: 60 kern.ipc.semmnu: 30 kern.ipc.semmsl: 60 root@dev:~# sysctl -w kern.ipc.semmap=50 kern.ipc.semmap: 30 - 50 root@dev:~# sysctl -w kern.ipc.semmni=50 sysctl: oid 'kern.ipc.semmni' is read only root@dev:~# On 20 Nov 2002, Neil Conway wrote: The documentation on changing shared memory kernel settings on xBSD (namely FreeBSD, possibly others as well) isn't ideal, IMHO. It says: %% The options SYSVSHM and SYSVSEM need to be enabled when the kernel is compiled. (They are by default.) The maximum size of shared memory is determined by the option SHMMAXPGS (in pages). The following shows an example of how to set the various parameters: options SYSVSHM options SHMMAXPGS=4096 options SHMSEG=256 options SYSVSEM options SEMMNI=256 options SEMMNS=512 options SEMMNU=256 options SEMMAP=256 (On NetBSD and OpenBSD the key word is actually option singular.) You may also want to use the sysctl setting to lock shared memory into RAM and prevent it from being paged out to swap. %% However, it appears that shared memory semaphore settings can also be controlled via sysctls -- at least on a FreeBSD 4.7-RELEASE box, I can see: kern.ipc.semmap: 30 kern.ipc.semmni: 10 kern.ipc.semmns: 60 kern.ipc.semmnu: 30 kern.ipc.semmsl: 60 kern.ipc.semopm: 100 kern.ipc.semume: 10 kern.ipc.semusz: 92 kern.ipc.semvmx: 32767 kern.ipc.semaem: 16384 kern.ipc.shmmax: 33554432 kern.ipc.shmmin: 1 kern.ipc.shmmni: 192 kern.ipc.shmseg: 128 kern.ipc.shmall: 8192 kern.ipc.shm_use_phys: 0 However, the FreeBSD box I'm playing with isn't mine, so I'm not too keen to change sysctls (well, that and I don't have root :-) ). Would a kind BSD user confirm that: (a) the sysctls above *can* be used to change kernel shared memory settings, and the default value of the sysctl is the kernel option referred to in the docs. (b) do the above sysctls work on NetBSD and OpenBSD as well? (c) the 'prevent shared memory paging' sysctl vaguely referred to in the docs is 'kern.ipc.shm_use_phys', right? (d) does the above sysctl also work on NetBSD and OpenBSD? Thanks in advance, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
