Re: [BUGS] _bt_check_unique checks every row in table when doing update??
[EMAIL PROTECTED] (Tom Lane) writes: > Mats Lofkvist <[EMAIL PROTECTED]> writes: > > But when doing ~1000 updates (i.e. setting val0 and val1 with > > a where on an existing key0/key1/key2 triplet), I get this which > > seems very strange to me: > > I suppose you repeatedly updated the same row 1000 times? That creates > an O(N^2) behavior because the dead tuples have to be rechecked again > and again. > > 7.3 will be smarter about this. > > regards, tom lane Yes, I did update the same row so your explanation is correct. (Note that I also read the data wrong, for some reason I read it as 500k checks per 1 update, not per 1000 which made it look a lot worse than it is.) Thanks for the explanation, I'll try 7.3 beta to see how it works there. _ Mats Lofkvist [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] make unsuccessful on mac os x 10.2
Bruce, Thanks for the reply. It installed fine but when I ran initdb this was the output: [mikef-ti:/usr/local/pgsql] postgres% bin/initdb The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale en_US. This locale setting will prevent the use of indexes for pattern matching operations. If that is a concern, rerun initdb with the collation order set to "C". For more information see the Administrator's Guide. Fixing permissions on existing directory /usr/local/pgsql/data... ok creating directory /usr/local/pgsql/data/base... ok creating directory /usr/local/pgsql/data/global... ok creating directory /usr/local/pgsql/data/pg_xlog... ok creating directory /usr/local/pgsql/data/pg_clog... ok creating template1 database in /usr/local/pgsql/data/base/1... Failed to initialize lc_time to '' ok creating configuration files... ok initializing pg_shadow... Failed to initialize lc_time to '' ok enabling unlimited row size for system tables... Failed to initialize lc_time to '' ok initializing pg_depend... Failed to initialize lc_time to '' ok creating system views... Failed to initialize lc_time to '' ok loading pg_description... Failed to initialize lc_time to '' ok creating conversions... Failed to initialize lc_time to '' ok setting privileges on built-in objects... Failed to initialize lc_time to '' ok vacuuming database template1... Failed to initialize lc_time to '' ok copying template1 to template0... Failed to initialize lc_time to '' ok Success. You can now start the database server using: bin/postmaster -D /usr/local/pgsql/data or bin/pg_ctl -D /usr/local/pgsql/data -l logfile start --- It failed on startup afterwards. I tried the --lc-time 'en_US' flag but it made no difference. Any other suggestions would be appreciated. Thanks, Michael On Monday, September 9, 2002, at 10:18 PM, Bruce Momjian wrote: > > Get 7.3beta1 for OSX 10.2. > > --- > > > Michael Fortin wrote: >> My guess is that the new compiler in 10.2 is not compatible with >> postgres. Here is the output from configure and make: >> >> [mikef-ti:/database/postgresql-7.2.2] mikef% ./configure --with-java >> loading cache ./config.cache >> checking host system type... powerpc-apple-darwin6.0 >> checking which template to use... darwin >> checking whether to build with locale support... no >> checking whether to build with recode support... no >> checking whether to build with multibyte character support... no >> checking whether NLS is wanted... no >> checking for default port number... 5432 >> checking for default soft limit on number of connections... 32 >> checking for gcc... (cached) gcc >> checking whether the C compiler (gcc ) works... yes >> checking whether the C compiler (gcc ) is a cross-compiler... no >> checking whether we are using GNU C... (cached) yes >> checking whether gcc accepts -g... (cached) yes >> using CFLAGS=-g -O2 >> checking whether the C compiler (gcc -traditional-cpp -g -O2 ) >> works... >> yes >> checking whether the C compiler (gcc -traditional-cpp -g -O2 ) is a >> cross-compiler... no >> checking for Cygwin environment... (cached) no >> checking for mingw32 environment... (cached) no >> checking for executable suffix... (cached) no >> checking how to run the C preprocessor... (cached) gcc >> -traditional-cpp >> -E >> checking whether gcc -traditional-cpp needs -traditional... (cached) >> no >> checking whether to build with Tcl... no >> checking whether to build with Tk... no >> checking whether to build Perl modules... no >> checking whether to build Python modules... no >> checking whether to build Java/JDBC tools... yes >> checking for jakarta-ant... no >> checking for ant... /java/jakarta-ant-1.5/bin/ant >> checking whether /java/jakarta-ant-1.5/bin/ant works... yes >> checking whether to build with PAM support... no >> checking whether to build the ODBC driver... no >> checking whether to build C++ modules... no >> using CPPFLAGS= >> using LDFLAGS= >> checking for mawk... (cached) awk >> checking for flex... (cached) /usr/bin/flex >> checking whether ln -s works... (cached) yes >> checking for ld used by GCC... (cached) /usr/bin/ld >> checking if the linker (/usr/bin/ld) is GNU ld... (cached) no >> checking for ranlib... (cached) ranlib >> checking for lorder... (cached) lorder >> checking for tar... (cached) /usr/bin/tar >> checking for bison... (cached) bison -y >> checking for perl... (cached) /usr/bin/perl >> checking for readline... (cached) no >> checking for library containing using_history... (cached) no >> checking for main in -lbsd... (cached) no >> checking for setproctitle in -lutil... (cached) no >> checking for main in -lm... (cached) yes >> checking for main in -ldl... (cached) no >> checking for main in -lsocket... (cached) no >> checking for main i
Re: [BUGS] make unsuccessful on mac os x 10.2
Yes, it's 10.2. My environment is pretty much out of the box. I did a clean install about a week ago and I really haven't had much time to customize it. [mikef-ti:~] mikef% env HOME=/Users/mikef SHELL=/bin/tcsh USER=mikef LANG=en_US PATH=/bin:/sbin:/usr/bin:/usr/sbin __CF_USER_TEXT_ENCODING=0x1F5:0:0 TERM=vt100 TERMCAP=¡Z¡Z¡Z TERM_PROGRAM=Apple_Terminal TERM_PROGRAM_VERSION=81 LOGNAME=mikef HOSTTYPE=macintosh VENDOR=apple OSTYPE=darwin MACHTYPE=powerpc SHLVL=1 PWD=/Users/mikef GROUP=staff HOST=mikef-ti.local. [mikef-ti:~] mikef% uname -a Darwin mikef-ti.local. 6.0 Darwin Kernel Version 6.0: Sat Jul 27 13:18:52 PDT 2002; root:xnu/xnu-344.obj~1/RELEASE_PPC Power Macintosh powerpc This are the only log entries produced at startup: Failed to initialize lc_time to '' FATAL: invalid value for option 'LC_TIME': 'en_US' I was looking at $PGDATA/postgresql.conf and the very last line in the file is LC_TIME = 'en_US' ,is this a coincidence? When I initially looked at it had no carriage return. I added a few more empty lines after it but that made no difference. Any other thoughts? Thanks Michael On Tuesday, September 10, 2002, at 01:03 AM, Bruce Momjian wrote: Oh, that's a strange error. I thought our beta1 worked on OSX 10.2. You are on 10.2, right? Do have have any environment variables starting with LC_*? --- Michael Fortin wrote: Bruce, Thanks for the reply. It installed fine but when I ran initdb this was the output: [mikef-ti:/usr/local/pgsql] postgres% bin/initdb The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale en_US. This locale setting will prevent the use of indexes for pattern matching operations. If that is a concern, rerun initdb with the collation order set to "C". For more information see the Administrator's Guide. Fixing permissions on existing directory /usr/local/pgsql/data... ok creating directory /usr/local/pgsql/data/base... ok creating directory /usr/local/pgsql/data/global... ok creating directory /usr/local/pgsql/data/pg_xlog... ok creating directory /usr/local/pgsql/data/pg_clog... ok creating template1 database in /usr/local/pgsql/data/base/1... Failed to initialize lc_time to '' ok creating configuration files... ok initializing pg_shadow... Failed to initialize lc_time to '' ok enabling unlimited row size for system tables... Failed to initialize lc_time to '' ok initializing pg_depend... Failed to initialize lc_time to '' ok creating system views... Failed to initialize lc_time to '' ok loading pg_description... Failed to initialize lc_time to '' ok creating conversions... Failed to initialize lc_time to '' ok setting privileges on built-in objects... Failed to initialize lc_time to '' ok vacuuming database template1... Failed to initialize lc_time to '' ok copying template1 to template0... Failed to initialize lc_time to '' ok Success. You can now start the database server using: bin/postmaster -D /usr/local/pgsql/data or bin/pg_ctl -D /usr/local/pgsql/data -l logfile start --- It failed on startup afterwards. I tried the --lc-time 'en_US' flag but it made no difference. Any other suggestions would be appreciated. Thanks, Michael On Monday, September 9, 2002, at 10:18 PM, Bruce Momjian wrote: Get 7.3beta1 for OSX 10.2. --- Michael Fortin wrote: My guess is that the new compiler in 10.2 is not compatible with postgres. Here is the output from configure and make: [mikef-ti:/database/postgresql-7.2.2] mikef% ./configure --with-java loading cache ./config.cache checking host system type... powerpc-apple-darwin6.0 checking which template to use... darwin checking whether to build with locale support... no checking whether to build with recode support... no checking whether to build with multibyte character support... no checking whether NLS is wanted... no checking for default port number... 5432 checking for default soft limit on number of connections... 32 checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes using CFLAGS=-g -O2 checking whether the C compiler (gcc -traditional-cpp -g -O2 ) works... yes checking whether the C compiler (gcc -traditional-cpp -g -O2 ) is a cross-compiler... no checking for Cygwin environment... (cached) no checking for mingw32 environment... (cached) no checking for executable suffix... (cached) no checking how to run the C preprocessor... (cached) gcc -traditional-cpp -E checking whether gcc -traditional-cpp needs -traditional... (cached) no checking whether to build with Tcl... no checking whether to build with Tk... no che
Re: [BUGS] make unsuccessful on mac os x 10.2
Michael Fortin <[EMAIL PROTECTED]> writes: > This are the only log entries produced at startup: > Failed to initialize lc_time to '' > FATAL: invalid value for option 'LC_TIME': 'en_US' The first of these is a mistake (Peter thought he'd fixed it a month ago, but his fix was incomplete; I believe I've fixed the fix, and am about to reboot into OSX to check). The second is OS X's bug: it ought to take en_US as a legal setting for LC_TIME, but seems not to. It is depressing that Apple evidently didn't fix that in 10.2. See prior discussion http://archives.postgresql.org/pgsql-admin/2002-08/msg00062.php It seems we have not done anything about trying to validate the user's LANG/LC_xxx environment settings, and so initdb is quite capable of accepting settings that will prevent the postmaster from starting. The short-term fix is to fix your LANG before initdb, or tweak the postgresql.conf file after. Oh, and file a bug report with Apple ;-) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] make unsuccessful on mac os x 10.2
Tom Lane wrote: > Michael Fortin <[EMAIL PROTECTED]> writes: > > This are the only log entries produced at startup: > > Failed to initialize lc_time to '' > > FATAL: invalid value for option 'LC_TIME': 'en_US' > > The first of these is a mistake (Peter thought he'd fixed it a month > ago, but his fix was incomplete; I believe I've fixed the fix, and am > about to reboot into OSX to check). The second is OS X's bug: it ought > to take en_US as a legal setting for LC_TIME, but seems not to. It is > depressing that Apple evidently didn't fix that in 10.2. See prior > discussion > http://archives.postgresql.org/pgsql-admin/2002-08/msg00062.php > > It seems we have not done anything about trying to validate the user's > LANG/LC_xxx environment settings, and so initdb is quite capable of > accepting settings that will prevent the postmaster from starting. > The short-term fix is to fix your LANG before initdb, or tweak the > postgresql.conf file after. And he is getting during initdb: >> The database cluster will be initialized with locale en_US. >> This locale setting will prevent the use of indexes for pattern >> matching >> operations. If that is a concern, rerun initdb with the collation >> order >> set to "C". For more information see the Administrator's Guide. which means that unless he really wants a special locale he should use C locale anyway. -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] make unsuccessful on mac os x 10.2
Tom Lane writes: > The second is OS X's bug: it ought to take en_US as a legal setting for > LC_TIME, but seems not to. It is depressing that Apple evidently didn't > fix that in 10.2. If it's only LC_TIME we can remove that since we don't use it anyway. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] ecpg hackery to get ecpg to compile from FreeBSD ports...
Sean Chittenden writes: > This is anecdotal for the archives, but the problem was that when > building with krb5, I had (wrongly?) appended krb5-config's --cflags > output to the CFLAGS for the build... which, nine times out of ten, > was exactly the same as what was used with the --with-includes. If > they're different, the person's horked, but that should be a minority > of the time. Anyway, just an FYI. The foo-config scripts are invariably bogus[*] -- don't use them. Especially if you're building in a predictable environment such as the ports tree you don't even need it since the location is known. [*] at least those that claim to give you the full CFLAGS, unlike pg_config -- Peter Eisentraut [EMAIL PROTECTED] ---(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: [BUGS] atan2 documentation bugs for 7.3 and 7.2
OK, patch applied. --- Bruno Wolff III wrote: > In the section on mathematical functions the following is given for atan2: > atan2(x, y) inverse tangent of a/x > > I believe the correct version should either be: > atan2(y, x) inverse tangent of y/x > or > atan2(x, y) inverse tangent of x/y > > I beleive the documentation was also wrong for 7.2 where it was: > atan2(x, y) inverse tangent of y/x > > The postgres functions seems to be the same as glibc function of the same > name when has the following man information: >double atan2(double y, double x); > > DESCRIPTION >The atan2() function calculates the arc tangent of the two >variables x and y. It is similar to calculating the arc >tangent of y / x, except that the signs of both arguments >are used to determine the quadrant of the result. > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- 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 Index: func.sgml === RCS file: /cvsroot/pgsql-server/doc/src/sgml/func.sgml,v retrieving revision 1.120 diff -c -r1.120 func.sgml *** func.sgml 2 Sep 2002 05:53:23 - 1.120 --- func.sgml 11 Sep 2002 02:54:46 - *** *** 743,749 atan2(x, y) inverse tangent of ! a/x --- 743,749 atan2(x, y) inverse tangent of ! x/y ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] make unsuccessful on mac os x 10.2
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: >> The second is OS X's bug: it ought to take en_US as a legal setting for >> LC_TIME, but seems not to. It is depressing that Apple evidently didn't >> fix that in 10.2. > If it's only LC_TIME we can remove that since we don't use it anyway. No such luck; LC_MONETARY and LC_NUMERIC have the same problem. I'm not sure why Michael saw LC_TIME as the first failure, 'cause all three fail for me on OS X 10.1. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Bug #759: 7.3beta1 DROP COLUMN DEPENDENCY PROBLEM
Is this a TODO item or something for beta2? --- Rod Taylor wrote: > On Fri, 2002-09-06 at 19:30, Tom Lane wrote: > > Rod Taylor <[EMAIL PROTECTED]> writes: > > > The big difference is that the INNER JOIN code needs to drop one of the > > > colb's coming up with a virtual relation cola, colb, colc; where the > > > other doesn't have such a renaming scheme. > > > > On reflection I think it might be possible to make this work the way > > Tim wants: I think it would be okay for the dependency-extracter code > > to ignore the Var lists that are attached to join RTEs. Needs more > > thought though, and I don't plan to think about it before Monday; > > I'm taking the weekend off ... > > Your right. The view continues to function perfectly fine with the > column dropped (did a delete from pg_depend to allow it). > > > ---(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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Bug #759: 7.3beta1 DROP COLUMN DEPENDENCY PROBLEM
Bruce Momjian <[EMAIL PROTECTED]> writes: > Is this a TODO item or something for beta2? I have patches on my laptop to fix this, and will commit once I've tested 'em a little more. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
