Re: [BUGS] debug_level 0 does not stop debug messages
Sure, I have about 70 tables, each vacuum prints out something like this per table. You'll notice it prints stuff for each index also. postgres[23034]: [566] DEBUG: --Relation test-- postgres[23034]: [567-1] DEBUG: Pages 1: Changed 1, reaped 1, Empty 0, New 0; Tup 3: Vac 1, Keep/VTL 0/0, Crash 0, UnUsed 14, MinLen 67, MaxLen 67; postgres[23034]: [567-2] Re-using: Free/Avail. Space 7896/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec. postgres[23034]: [568] DEBUG: Index test_pkey: Pages 2; Tuples 3: Deleted 1. CPU -1.99s/0.00u sec. Also, on a side note, I read a post to the list about 2 weeks ago about you writing a performance tuning document and putting it up on the website. Did this happen and I miss it, or is it still in the works? Thanks, Jon Poland On Thu, 3 May 2001, Bruce Momjian wrote: > > Can you give me a few sample lines that you are seeing in the log? > > > Hi, > > I'm not using pg_ctl, I'm using postmaster directly. So, in my case I > > tried passing "-d0" to it, but it had no effect. Command line: > > > > postmaster -i -d0 -D /var/pgsql/data -c syslog=2 > > > > Any ideas? I could patch the code to remove the excessive elog's in the > > vacuum command, but I'd rather understand how elog interacts with the > > global DebugLvl variable. > > > > JP > > > > On Tue, 1 May 2001, Justin Clift wrote: > > > Hi, > > > > > > This might sound weird, but try " > > > > > > pg_ctl start -o '-d0' > > > > > > Include any other options you need of course too. The point is not > > > having a space between the -d and the 0. > > > > > > This fixes things for me when I have the default startup options > > > different, but need logging off for a while. > > > > > > Regards and best wishes, > > > > > > Justin Clift > > > > > > [EMAIL PROTECTED] wrote: > > > > > > > > JP ([EMAIL PROTECTED]) reports a bug with a severity of 2 > > > > The lower the number the more severe it is. > > > > > > > > Short Description > > > > debug_level 0 does not stop debug messages > > > > > > > > Long Description > > > > I'm trying to silence the annoying output generated by vacuum. I've > > > > tried both command line options (-d 0, -S (with syslog enabled)) and > > > > postgresql.conf (debug_level = 0, silent_mode = 1). Setting debug > > > > level to 0 should silence these messages, but still let errors through. >Setting debug level higher seems to generate more output, which is great. just be >nice if the vacuum output were at level 3 or > > > > greater. > > > > > > > > Platform: OpenBSD 2.8 (i386) > > > > PG Version: 7.1 > > > > > > > > Sample Code > > > > > > > > No file was uploaded with this report > > > > > > > > ---(end of broadcast)--- > > > > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > > > > > > -- > > > "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 4: Don't 'kill -9' the postmaster > > > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] PostgreSQL bug in SELECT DISTINCT
Tom Lane wrote: >"J.R. Onyschak" <[EMAIL PROTECTED]> writes: > >>When I execute the following query: >>SELECT DISTINCT title FROM division ORDER BY UPPER(title); >> >>I get: >>ERROR: For SELECT DISTINCT, ORDER BY expressions must appear in target list >> >>If I remove DISTINCT, the query works fine. >> >>Is this illegal or a known bug? >> > >This is not a bug, but an intentional restriction to prevent ill-defined >query results. Why don't you just "ORDER BY title"? > > regards, tom lane > I can't/don't want to "ORDER BY title" because the title might be entered as upper case or lower case. If we had divisions with titles Transportation, parks, and Education. I would like to display the results alphabetical regardless of capitalization. I know this example is a little contrived because all divisions should be capitalized, but we have a number of "objects" backed by tables that have a title column that we order by and some of them have a high chance of having mixed capitalization.I can understand the prevention of ill-defined query results, but is PostgreSql being too restrictive? I am ordering by a column in the select clause, I am just using a function on that column. Thanks for the great product. It truely has been fun using PostgreSql.Very robust, very easy to use. Thank you for your help, jr P.S. I don't mean for this to sound whiny, but I encounterd this in porting a project from using Oracle to PostgreSql, so I know that Oracle supports it and other people might run into this problem. P.P.S. Where can I locate a copy of the latest SQL spec? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Re: PostgreSQL bug in SELECT DISTINCT
Thomas Lockhart wrote: >>When I execute the following query: >>SELECT DISTINCT title FROM division ORDER BY UPPER(title); >>I get: >>ERROR: For SELECT DISTINCT, ORDER BY expressions must appear in target list >>If I remove DISTINCT, the query works fine. >>Is this illegal or a known bug? >> > >Illegal. I believe that allowing any function call in the "order by" >clause is an extension to SQL9x, so feel lucky that you can do it at all >;) > Where can I look at a copy of the SQL spec? I've tried to locate it online, but haven't been able to find it. > > >However, > >SELECT T FROM (SELECT DISTINCT title FROM division) AS T ORDER BY >UPPER(T); > >seems to work in 7.1 (but not in earlier releases). This give PostgreSQL >a chance to hold an intermediate result to sort in a second pass. > > - Thomas > That's interesting. I remember that, but I don't think I should rely on it because I am trying to keep our SQL code portable across databases. (We've already made once change and might have to do another) Thanks for your time, J.R. ---(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] freebsd sample startup script doesn't work
> "PE" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Also, the following line in the start action of the sript is useful:
>>
>> /sbin/ldconfig -m $prefix/lib
PE> You ought to run this once, not every time the system starts.
No, FreeBSD does *not* cache this info. You need to run it on every
system startup, unless you're libs are in /usr/lib or /usr/local/lib
or you've altered FreeBSD's setting of ldconfig_paths in the system
startup scripts.
Here's what I'm using, as file /usr/local/etc/rc.d/00postgres-client.sh,
as opposed to running it in the server startup script.
--cut here--
#!/bin/sh
case "$1" in
start)
/sbin/ldconfig -m /usr/local/pgsql/lib
;;
stop)
;;
*)
echo ""
echo "Usage: `basename $0` { start | stop }"
echo ""
exit 64
;;
esac
--cut here--
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.Khera Communications, Inc.
Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] freebsd sample startup script doesn't work
> "BM" == Bruce Momjian <[EMAIL PROTECTED]> writes: BM> Got it. I recommend changing 'su -l' to 'su -m' to preserve the BM> environment. How does that sound? Just tried it and it works ok. The only issue I can think of is if root has some secret info in the environment, that it will now be accessible to postgres... but then who puts secret info in their environment? ;-) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] freebsd sample startup script doesn't work
> "PE" == Peter Eisentraut <[EMAIL PROTECTED]> writes: PE> Sure it does. See 'var/run/ld[-elf].so.hints'. But /var/run is not guaranteed to survive reboot. "man hier" has this to say about it: run/ system information files describing various info about system since it was booted Says nothing about prior to booting. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] insert into select from
POSTGRESQL BUG REPORT TEMPLATE Your name : Jan Branbergen Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel PII Operating System (example: Linux 2.0.26 ELF) : NetBSD PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.3 Compiler used (example: gcc 2.8.0) : Please enter a FULL description of your problem: When i do a "NSERT INTO screen_filter_field( screen_filter_id, screen_field_id, seqno, visible, orderno ) SELECT 182, id, seqno, visible, orderno FROM screen_field WHERE screen_id = 1" i get a permission denied on table screen_field; i have select, insert, update & delete access to table screen_filter_field, and select access to table b. when i add update access to table b, the statement executes fine. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- If you know how this problem might be fixed, list the solution below: - no idea ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
RE: [BUGS] Found an example prooving bug
> From my point of view, NULL is neither bigger, nor smaller, you can't > compare it with a number. > So it just comes at the end if you sort at all. Well, I know you can't compare null in, for example, WHERE clause. But if we want to sort data in some way, I would like Postgres to behave in any, but predictable, way. If last of the query execution steps is sorting, null values are always at the end. And it would be OK, but, depending on the query, values in database, and some options (like ENABLE_SORT), null-values are sometimes at the beginning, because it uses order stored in index. Also, for my bug-report Tom Lane replied with some details from SQL92 specs. And my last mail, with an example (I can wrote less complex one) shows, that pgsql doesn't work the way SQL92 says. So, is it compliant with SQL92 standard in this matter or is it not? If it's not, shouldn't that be changed? > (Perhaps you need to take a think about what NULL means in your data. Should > NULL sort as if it's 0?, +infinity?, -infinity? if so why?) As I wrote - any way. But fixed one. To finish this problem - I've changed my program to use -infinity for null values (but I really don't like it :) ). I still think pgsql is not compliant with SQL92, but I'm not the one to decide if it should be changed. Best regards Marcin Zukowski ---(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] freebsd sample startup script doesn't work
> "VK" == Vivek Khera <[EMAIL PROTECTED]> writes: > "PE" == Peter Eisentraut <[EMAIL PROTECTED]> writes: PE> Sure it does. See 'var/run/ld[-elf].so.hints'. VK> But /var/run is not guaranteed to survive reboot. "man hier" has this VK> to say about it: One more thing... /etc/rc _explicitly_ sets the ldconfig path, overriding anything that may have been sitting in /var/run/ld-elf.so.hints anyhow. So you *must* do the ldconfig -m /usr/local/pgsql/lib every boot or you don't get those libs. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] insert into select from
"Jan Branbergen" <[EMAIL PROTECTED]> writes: > i have constraints defined on the tables to force ref integrity, but nothing > else. i can send my schema if you would like. If you have a foreign key reference from screen_filter_field to screen_filter, that would explain it --- but I'd expect you'd be seeing the permissions issue on any insert into screen_filter_field, not only an INSERT/SELECT. See past discussions about why the foreign key triggers use SELECT FOR UPDATE rather than plain SELECT. I am not sure whether this is any different in 7.1 ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [BUGS] insert into select from
"Jan Branbergen" <[EMAIL PROTECTED]> writes: > When i do a "NSERT INTO screen_filter_field( screen_filter_id, > screen_field_id, seqno, visible, orderno ) SELECT 182, id, seqno, visible, > orderno FROM screen_field WHERE screen_id = 1" i get a permission denied on > table screen_field; i have select, insert, update & delete access to table > screen_filter_field, and select access to table b. when i add update access > to table b, the statement executes fine. I can't duplicate this. Perhaps you have rules or triggers you didn't tell us about? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[BUGS] Build fails for pl/tcl on OpenBSD
POSTGRESQL BUG REPORT TEMPLATE Your name : Hentosh Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : AMD Athlon Operating System (example: Linux 2.0.26 ELF) : OpenBSD 2.8 PostgreSQL version (example: PostgreSQL-7.0): Todays CVS (pre 7.1.1) Compiler used (example: gcc 2.8.0) : 2.95.3 Please enter a FULL description of your problem: building with ./configure --enable-syslog works great. But when I use ./configure --enable-syslog --with-tcl --without-tk --enable-multibyte --enable-unicode-conversion --with-tclconfig=/usr/local/lib/tcl8.3 It fails with the following error when it compiles src/pl/tcl/pltcl.c: pltcl.c:38: tcl.h: No such file or directory This works on my linux box since tcl.h is in /usr/include but on OpenBSD it is located in /usr/local/include/tcl8.3/tcl.h Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- Install a base OpenBSD 2.8 system and add the following packages: bison-1.27.tgz gettext-0.10.35.tgz gmake-3.79.1.tgz tcl-8.3.2.tgz In addition to the above my system had its kernel recompiled to up shared mem and semephores. run the config line from above and then gmake. If you know how this problem might be fixed, list the solution below: - I think the Makefile doesn't take into account if the tcl stuff was placed in a non-standard location. Change line 66 in src/pl/tcl/Makefile to: override CFLAGS = $(TCL_CFLAGS_OPTIMIZE) $(TCL_SHLIB_CFLAGS) -I $(TCL_PREFIX)/include/tcl$(TCL_VERSION) ---(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] Build fails for pl/tcl on OpenBSD
Robert Hentosh <[EMAIL PROTECTED]> writes: > It fails with the following error when it compiles src/pl/tcl/pltcl.c: > pltcl.c:38: tcl.h: No such file or directory > This works on my linux box since tcl.h is in /usr/include but on OpenBSD it is >located in /usr/local/include/tcl8.3/tcl.h OpenBSD's tcl package is broken, then. It's their responsibility to put the necessary compiler flags into tclConfig.sh, not the responsibility of every Tcl-using software to second guess where the include files are. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Build fails for pl/tcl on OpenBSD
I said: > OpenBSD's tcl package is broken, then. It's their responsibility to put > the necessary compiler flags into tclConfig.sh, not the responsibility > of every Tcl-using software to second guess where the include files are. After thinking about this a little more, I'm confused again. How did you manage to get past src/interfaces/libpgtcl, which also includes tcl.h without benefit of any hand-hacked -I switches? I'm still of the opinion that adding -I $(TCL_PREFIX)/include/tcl$(TCL_VERSION) to src/pl/tcl/Makefile is an inappropriate thing to do. But it seems that the correct way to deal with nonstandardly-located packages is to say --with-includes=/usr/local/include/tcl8.3 to configure (more than likely you'll also need --with-libs=/usr/local/lib/tcl8.3), and I'm just wondering how come you didn't seem to need that to build libpgtcl. It shouldn't have gotten as far as pl/tcl ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
