[BUGS] unsubscribe pgsql-bugs@postgresql.org
unsubscribe [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] problem with 8.0rc1 not using indexes(solved)
Tony Caduto wrote: Well, I got my 8.0 RC1 working the same as my 7.4.5 and it is for sure because of some difference in the SQL engine. On my 7.4.5 box I had the following in the postgresql.conf file: enable_seqscan = true (this is the default setting) 7.4.5 had no problems using the indexes with this setting = true on 8.0RC1 it refused to use certain indexes if enable_seqscan = true I set this value to false on 8.0 and my performance came back to the 7.4.5 levels. Is there some other setting in the conf file that would affect the optimizer? The weird part is if I ran each query in the function by itself Explain would always report the index being used, but when run in the context of the function the indexes where not being used. Is not solved because is a bad idea run the server with that parameter disabled. Regards Gaetano Mendola ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #1352: 100's of postgres.exe tasks created
The following bug has been logged online: Bug reference: 1352 Logged by: Steve Schafer Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Beta Operating system: Windows 2000 Pro, sp 4, up to date Description:100's of postgres.exe tasks created Details: I know I could do more to make this reproducable but I'm don't have a lot of time and I figure it's better to at least report it. Maybe I'm doing something wrong that's making this happen. If so I'm sorry for wasting your time but I'd appreciate knowing what it is. This is 8.0.0rc1 installed on win2kpro from downloaded binaries. If there's a build number, I don't know where to find it. I browsed through the bugs forum but didn't see anything like this. I'm using postgresql with a complex java web application that creates many prepared statements which are used once and not reused. After running this application for a while, I can see a great many instances of postgres.exe running in the task manager. I've seen as many as a couple of hundred. The more I run my application, the more instances appear. Most of them have done no I/O. When I shut down the postgres service, these tasks do not go away. I cannot kill these tasks using the task manager because I get an access denied error. I've even had problems shutting down windows because each of these task pops up error windows. Prior to downloading 8.0.0rc1, I was using 7.4.1 in cygwin and never had this kind of problem. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] "pg_ctl -w" does not return a failure exit code when postmaster fails to start
I have noticed on linux that if you try to start postmaster via "pg_ctl -w", but the postmaster fails to run (e.g. if you forgot to create PGDATA), it returns a 0 exit code. It needs to return a non-0 exit code if postmaster failed to start, when you are using the "-w" option to wait for it to start. Thanks, Steve McWilliams ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] Problems with "-w" option on pg_ctl.exe running as a windows service
Hello, I tried sending this the other week but for some reason it hasn't gone through, so I am resending: I am using Postgresql-8.0.0beta4 on Windows XP Pro and have noticed that attempts to run pg_ctl as a service fail when the "-w" option is included. So if I register the service as follows: pg_ctl.exe -N my_svc -w -U my_user -P my_pword -D my_dir -o "-i -p 15432" then try to start the service via the GUI service manager panel, it pops up an error dialog saying the service started but then stopped immediately. If I remove the "-w" option from the above line when it is registered, then I am able to start the service just file. The usage documentation for pg_ctl indicates you are supposed to be able to include the "-w" option when you register it as a service. I would like to be able to use it, so that when Windows launches postgres, it is not declared to be in the fully running state prematurely. We have another service that we launch which declares a dependency on postgres, however that dependency declaration is meaningless if postgres announces that it is fully running before it is truly able to accept clients. Any suggestions? For a temporary work around I have hacked my pg_ctl.c to wait 5 seconds before declaring the service to be in the running state. Thanks in advance. Steve McWilliams ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Polymorphism resgression test fails when BLCKSZ changed
Hi, The regression test fails on 'polymorphism' on three different computers with various architectures. (I hope this point was not raised before, but I did not find any relevant mail about it with '[BUGS]'in the subject line and 'polymorphism' in message body) Besides the configure options stated below, BLCKSZ was redefined from 8192 to 16384 before running configure. With default vakue (8192) make check runs smoothly. Machine 1 : (SuSE 8.2 i386) --- uname -m = i686 uname -r = 2.4.20-64GB-SMP uname -s = Linux uname -v = #1 SMP Wed Nov 17 20:29:59 UTC 2004 gcc 3.3.1 ./configure '--prefix=/usr' '--libdir=/usr/lib' '--bindir=/usr/bin' '-- includedir=/usr/include/pgsql' '--datadir=/usr/share/postgresql' '-- mandir=/usr/share/man' '--with-docdir=/usr/share/doc/packages' '--with- includes=/usr/include/heimdal /usr/include/et' '--disable-rpath' '--enable- nls' '--enable-thread-safety' '--enable-integer-datetimes' '--with-python' '-- with-perl' '--with-tcl' '--without-tk' '--with-openssl' '--with-pam' 'CFLAGS=- O3 -march=pentium3 -mcpu=pentium3 -fmessage-length=0 -Wall' Machine 2 : (SuSE 9.1 i386) --- uname -m = i686 uname -r = 2.6.5-7.111.5-default uname -s = Linux uname -v = #1 Wed Nov 17 11:08:17 UTC 2004 gcc 3.3.3 ./configure '--prefix=/usr' '--libdir=/usr/lib' '--bindir=/usr/bin' '-- includedir=/usr/include/pgsql' '--datadir=/usr/share/postgresql' '-- mandir=/usr/share/man' '--with-docdir=/usr/share/doc/packages' '--with- includes=/usr/include/heimdal /usr/include/et' '--disable-rpath' '--enable- nls' '--enable-thread-safety' '--enable-integer-datetimes' '--with-python' '-- with-perl' '--with-tcl' '--without-tk' '--with-openssl' '--with-pam' '--with- krb5' 'CFLAGS=-O3 -march=pentium3 -mcpu=pentium3 -fmessage-length=0 -Wall' Machine 3 : (IBM R/S 6000 - powerpc-ibm-aix4.3.3.0) --- uname -m = 0057C2BA4C00 uname -r = 3 uname -s = AIX uname -v = 4 xlc C for AIX Compiler, Version 5 ./configure --without-readline --without-zlib ---(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] Polymorphism resgression test fails when BLCKSZ changed
[EMAIL PROTECTED] writes: > The regression test fails on 'polymorphism' on three different computers with > various architectures. Define "fails" (regression diffs output would be nice). > Besides the configure options stated below, BLCKSZ was redefined from 8192 to > 16384 before running configure. If it's just a change in output row order then it's not a bug ... regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] Problems with "-w" option on pg_ctl.exe running as a windows
Looking at the two patches I just applied I think it might fix your problem. The problem was actually the general problem of pg_ctl -w start not returning a non-zero. --- Steve McWilliams wrote: > Hello, > > I tried sending this the other week but for some reason it hasn't gone > through, so I am resending: > > I am using Postgresql-8.0.0beta4 on Windows XP Pro and have noticed that > attempts to run pg_ctl as a service fail when the "-w" option is included. > So if I register the service as follows: > > pg_ctl.exe -N my_svc -w -U my_user -P my_pword -D my_dir -o "-i -p 15432" > > then try to start the service via the GUI service manager panel, it pops > up an error dialog saying the service started but then stopped > immediately. If I remove the "-w" option from the above line when it is > registered, then I am able to start the service just file. > > The usage documentation for pg_ctl indicates you are supposed to be able > to include the "-w" option when you register it as a service. I would > like to be able to use it, so that when Windows launches postgres, it is > not declared to be in the fully running state prematurely. We have > another service that we launch which declares a dependency on postgres, > however that dependency declaration is meaningless if postgres announces > that it is fully running before it is truly able to accept clients. > > Any suggestions? For a temporary work around I have hacked my pg_ctl.c to > wait 5 seconds before declaring the service to be in the running state. > Thanks in advance. > > Steve McWilliams > > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- 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: [BUGS] Polymorphism resgression test fails when BLCKSZ changed
It appears to be just that.
Great, It works!
*** ./expected/polymorphism.out Wed Dec 1 20:00:56 2004
--- ./results/polymorphism.out Tue Dec 21 19:06:12 2004
***
*** 349,532
select f3, myaggp01a(*) from t group by f3;
f3 | myaggp01a
+---
c | {}
a | {}
- b | {}
(3 rows)
select f3, myaggp03a(*) from t group by f3;
f3 | myaggp03a
+---
c | {}
a | {}
- b | {}
(3 rows)
select f3, myaggp03b(*) from t group by f3;
f3 | myaggp03b
+---
c | {}
a | {}
- b | {}
(3 rows)
select f3, myaggp05a(f1) from t group by f3;
f3 | myaggp05a
+---
c | {1,2}
a | {1,2,3}
- b | {1,2,3}
(3 rows)
select f3, myaggp06a(f1) from t group by f3;
f3 | myaggp06a
+---
c | {}
a | {}
- b | {}
(3 rows)
---8<--- SNIP ---
--- 349,532
select f3, myaggp01a(*) from t group by f3;
f3 | myaggp01a
+---
+ b | {}
c | {}
a | {}
(3 rows)
select f3, myaggp03a(*) from t group by f3;
f3 | myaggp03a
+---
+ b | {}
c | {}
a | {}
(3 rows)
select f3, myaggp03b(*) from t group by f3;
f3 | myaggp03b
+---
+ b | {}
c | {}
a | {}
(3 rows)
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, December 21, 2004 6:58 PM
Subject: Re: [BUGS] Polymorphism resgression test fails when BLCKSZ changed
> [EMAIL PROTECTED] writes:
> > The regression test fails on 'polymorphism' on three different computers
with
> > various architectures.
>
> Define "fails" (regression diffs output would be nice).
>
> > Besides the configure options stated below, BLCKSZ was redefined from 8192
to
> > 16384 before running configure.
>
> If it's just a change in output row order then it's not a bug ...
>
> regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] BUG #1329: Bug in IF-ELSEIF-ELSE construct
Awhile back I wrote: >> As long as you only do this in check_function_bodies mode it seems >> safe enough. One possible problem (if it's done towards the end of >> parsing as you've suggested for dead-code checking) is that a syntax >> error in a SQL statement might confuse the plpgsql parser into >> misparsing statement boundaries, which could lead to a plpgsql parse >> error much further down, such as a "missing END" at the end of the >> function. The error would be more useful if reported immediately >> after the putative SQL statement is parsed. Not sure if that's >> hard or not. (The same remark applies to dead code checking, now >> that I think about it.) A real-world example of why this would be useful can be seen at http://archives.postgresql.org/pgsql-novice/2004-12/msg00223.php The problem is a missing semicolon just before an IF construct. If the putative PERFORM were SQL-parsed right away, the user could see what had been taken as the body of the PERFORM and would be able to figure out his mistake. If we continue plpgsql-parsing it's very hard to see how we avoid generating an error that leads the user to look in the wrong place. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
