Re: [BUGS] Initdb Bug
[Charset ISO-8859-1 unsupported, filtering to ASCII...] > Tom Lane writes: > > > Or possibly he's invoking the right initdb, but it's finding the wrong > > postgres binary. > > Or the wrong template files? Run initdb --show to see. > > > I wonder if we can get initdb to check that it's > > invoking the right version of 'postgres'? A display of the version > > number wouldn't be a bad idea either. > > I know I might have had a different opinion on this before but I'm > beginning to think that the path to any auxiliary programs needs to be I understand your concern. My question is how does someone access initdb without getting binaries of the same version? Seems it may be happening, but how? -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [BUGS] Error in pgaccess (parse error at or near """) on createnew user with password
Applied. Pgaccess author will apply it there.
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> [syntax change WITH PASSWORD "foo" -> WITH PASSWORD 'foo']
>
> Here's a patch. (I think. I'm a bloody Tcl amateur.) What do we do with
> it?
>
>
> *** pgsql-cvs/src/bin/pgaccess/lib/users.tcl Sat Oct 30 18:18:49 1999
> --- pgsql/src/bin/pgaccess/lib/users.tcl Fri May 12 13:57:28 2000
> *** proc {save} {} {
> *** 63,69
> }
> set cmd "$PgAcVar(user,action) user \"$PgAcVar(user,name)\""
> if {$PgAcVar(user,password)!=""} {
> ! set cmd "$cmd WITH PASSWORD \"$PgAcVar(user,password)\" "
> }
> set cmd "$cmd $PgAcVar(user,createdb) $PgAcVar(user,createuser)"
> if {$PgAcVar(user,validuntil)!=""} {
> --- 63,69
> }
> set cmd "$PgAcVar(user,action) user \"$PgAcVar(user,name)\""
> if {$PgAcVar(user,password)!=""} {
> ! set cmd "$cmd WITH PASSWORD '$PgAcVar(user,password)' "
> }
> set cmd "$cmd $PgAcVar(user,createdb) $PgAcVar(user,createuser)"
> if {$PgAcVar(user,validuntil)!=""} {
>
>
> --
> Peter Eisentraut Sernanders v_g 10:115
> [EMAIL PROTECTED] 75262 Uppsala
> http://yi.org/peter-e/Sweden
>
>
--
Bruce Momjian| http://www.op.net/~candle
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [BUGS] minor bug: unlisten
Jeff Davis <[EMAIL PROTECTED]> writes: > Regarding UNLISTEN: 'UNLISTEN ' does not remove > LISTEN entries for '' in 'pg_listener' class, > nor does it prevent NOTIFYication. It appears that this breakage is due to failure to maintain the index on pg_listener that was added in 7.0. UNLISTEN is the only operation that tries to use the index, and it's failing because there are paths in async.c that don't bother to create an index entry for inserted tuples. Another way to show there is a problem is: regression=# vacuum pg_listener; VACUUM regression=# listen test; LISTEN regression=# vacuum pg_listener; NOTICE: Index pg_listener_relname_pid_index: NUMBER OF INDEX' TUPLES (0) IS NOT THE SAME AS HEAP' (1). Recreate the index. VACUUM As far as I can tell, the index on pg_listener doesn't even begin to approach usefulness; speeding up UNLISTEN (which most apps never do at all, or at most once) is a poor return on the cost of updating the index (twice!) for every NOTIFY. Therefore, rather than adding the missing code, what I'd really like to do is rip out the index and revert async.c to its indexless state. However, I don't see any way to get rid of that index completely without an initdb, and it's too late for initdb in the 7.0 cycle. If the index exists and async.c simply doesn't bother to update it, then we'll get notices like the above from VACUUM. Can anyone see a way around that? regards, tom lane
Re: [BUGS] Small bug with numeric in 7.0 (also in 6.5.3)
> Raul Chirea <[EMAIL PROTECTED]> writes: > > So, it seems to be a parser difficulty (bug) to correctly determine > > the type of a numeric constant with decimals (like 99.9). > > Yes. You can find more about this in the pgsql-hackers archives. > We've been aware of the problem for a while but are unsure as yet > how to solve it without breaking other cases --- ie, cases where > you *do* want such a constant to be treated as float not numeric. > > For the moment, we have left the behavior as it's always been in > Postgres (ie, undecorated non-integral constants are taken to be > 'float8'), so as not to break existing applications. Yikes: test=> create table tab1(x numeric); CREATE test=> insert into tab1 values (1); INSERT 20937 1 test=> update tab1 set x=4 where x=5; UPDATE 0 test=> update tab1 set x=4.0 where x=5; UPDATE 0 test=> update tab1 set x=4 where x=5.0; ERROR: Unable to identify an operator '=' for types 'numeric' and 'float8' You will have to retype this query using an explicit cast test=> This is terrible. I can't imagine how people use this without terrible problems. Why don't we get more bug reports about this? -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [BUGS] Small bug with numeric in 7.0 (also in 6.5.3)
Raul Chirea <[EMAIL PROTECTED]> writes: > So, it seems to be a parser difficulty (bug) to correctly determine > the type of a numeric constant with decimals (like 99.9). Yes. You can find more about this in the pgsql-hackers archives. We've been aware of the problem for a while but are unsure as yet how to solve it without breaking other cases --- ie, cases where you *do* want such a constant to be treated as float not numeric. For the moment, we have left the behavior as it's always been in Postgres (ie, undecorated non-integral constants are taken to be 'float8'), so as not to break existing applications. regards, tom lane
Re: [BUGS] Small bug with numeric in 7.0 (also in 6.5.3)
Hi there, It happened to me, too ! Denis Sbragion wrote: > pgsql=# UPDATE aocc SET controvalore_ord = 320.5 WHERE controvalore_ord = 320.5 > 00 AND oid = 21624; > ERROR: Unable to identify an operator '=' for types 'numeric' and 'float8' > You will have to retype this query using an explicit cast Strange is that if you try something like this: pgsql=# update set = where = ; it works. So, it seems to be a parser difficulty (bug) to correctly determine the type of a numeric constant with decimals (like 99.9). A guru opinion is, still, required ! Bye.
Re: [BUGS] Initdb Bug
Bruce Momjian <[EMAIL PROTECTED]> writes: >> I know I might have had a different opinion on this before but I'm >> beginning to think that the path to any auxiliary programs needs to be > I understand your concern. My question is how does someone access > initdb without getting binaries of the same version? > Seems it may be happening, but how? One easy way would be to type an explicit path to an initdb that's not in your PATH (and, therefore, its associated postgres binary isn't either). For instance, "./initdb" would fail if . is either not in your PATH or placed later than a directory containing another version of postgres... regards, tom lane
Re: [BUGS] minor bug: unlisten
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > while (HeapTupleIsValid(lTuple = heap_getnext(sRel, 0)))
> > + {
> > heap_delete(lRel, &lTuple->t_self, NULL);
> > + if (RelationGetForm(lRel)->relhasindex)
> > + {
> > + Relationidescs[Num_pg_listener_indices];
>
> > + CatalogOpenIndices(Num_pg_listener_indices,
>Name_pg_listener_indices, idescs);
> > + CatalogIndexInsert(idescs, Num_pg_listener_indices, lRel, rTuple);
> > + CatalogCloseIndices(Num_pg_listener_indices, idescs);
> > + }
> > + }
>
> What?? heap_delete doesn't require index updates AFAIK. Have you
> tested this?
No. I was about to, though. Backing it out now.
--
Bruce Momjian| http://www.op.net/~candle
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [BUGS] minor bug: unlisten
Bruce Momjian <[EMAIL PROTECTED]> writes:
> while (HeapTupleIsValid(lTuple = heap_getnext(sRel, 0)))
> + {
> heap_delete(lRel, &lTuple->t_self, NULL);
> + if (RelationGetForm(lRel)->relhasindex)
> + {
> + Relationidescs[Num_pg_listener_indices];
> + CatalogOpenIndices(Num_pg_listener_indices, Name_pg_listener_indices,
>idescs);
> + CatalogIndexInsert(idescs, Num_pg_listener_indices, lRel, rTuple);
> + CatalogCloseIndices(Num_pg_listener_indices, idescs);
> + }
> + }
What?? heap_delete doesn't require index updates AFAIK. Have you
tested this?
regards, tom lane
Re: [BUGS] minor bug: unlisten
OK, I have fixed the mistake I made that Tom pointed out. The fix will
be in 7.0.1. Tomorrow's snapshot will have it too.
Patch attached.
Thanks Tom.
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > Regarding UNLISTEN: 'UNLISTEN ' does not remove
> > LISTEN entries for '' in 'pg_listener' class,
> > nor does it prevent NOTIFYication.
>
> It appears that this breakage is due to failure to maintain the index
> on pg_listener that was added in 7.0. UNLISTEN is the only
> operation that tries to use the index, and it's failing because there
> are paths in async.c that don't bother to create an index entry for
> inserted tuples. Another way to show there is a problem is:
>
> regression=# vacuum pg_listener;
> VACUUM
> regression=# listen test;
> LISTEN
> regression=# vacuum pg_listener;
> NOTICE: Index pg_listener_relname_pid_index: NUMBER OF INDEX' TUPLES (0) IS NOT THE
>SAME AS HEAP' (1).
> Recreate the index.
> VACUUM
>
> As far as I can tell, the index on pg_listener doesn't even begin to
> approach usefulness; speeding up UNLISTEN (which most apps never do at
> all, or at most once) is a poor return on the cost of updating the index
> (twice!) for every NOTIFY. Therefore, rather than adding the missing
> code, what I'd really like to do is rip out the index and revert async.c
> to its indexless state.
>
> However, I don't see any way to get rid of that index completely without
> an initdb, and it's too late for initdb in the 7.0 cycle. If the index
> exists and async.c simply doesn't bother to update it, then we'll get
> notices like the above from VACUUM. Can anyone see a way around that?
>
> regards, tom lane
>
--
Bruce Momjian| http://www.op.net/~candle
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
? contrib/array/array_iterator.sql
? doc/src/sgml/app-psql.htm
? src/Makefile.custom
? src/crtags
? src/log
? src/config.log
? src/config.cache
? src/config.status
? src/GNUmakefile
? src/Makefile.global
? src/backend/fmgr.h
? src/backend/parse.h
? src/backend/postgres
? src/backend/global1.bki.source
? src/backend/local1_template1.bki.source
? src/backend/global1.description
? src/backend/local1_template1.description
? src/backend/catalog/genbki.sh
? src/backend/catalog/global1.bki.source
? src/backend/catalog/global1.description
? src/backend/catalog/local1_template1.bki.source
? src/backend/catalog/local1_template1.description
? src/backend/port/Makefile
? src/backend/utils/Gen_fmgrtab.sh
? src/backend/utils/fmgr.h
? src/backend/utils/fmgrtab.c
? src/bin/initdb/initdb
? src/bin/initlocation/initlocation
? src/bin/ipcclean/ipcclean
? src/bin/pg_ctl/pg_ctl
? src/bin/pg_dump/Makefile
? src/bin/pg_dump/pg_dump
? src/bin/pg_id/pg_id
? src/bin/pg_passwd/pg_passwd
? src/bin/pg_version/Makefile
? src/bin/pg_version/pg_version
? src/bin/pgaccess/pgaccess
? src/bin/pgtclsh/mkMakefile.tcldefs.sh
? src/bin/pgtclsh/mkMakefile.tkdefs.sh
? src/bin/pgtclsh/Makefile.tkdefs
? src/bin/pgtclsh/Makefile.tcldefs
? src/bin/pgtclsh/pgtclsh
? src/bin/pgtclsh/pgtksh
? src/bin/psql/ish
? src/bin/psql/Makefile
? src/bin/psql/psql
? src/bin/scripts/createlang
? src/include/version.h
? src/include/config.h
? src/interfaces/ecpg/lib/Makefile
? src/interfaces/ecpg/lib/libecpg.so.3.1.0
? src/interfaces/ecpg/preproc/Makefile
? src/interfaces/ecpg/preproc/ecpg
? src/interfaces/jdbc/DriverClass.class
? src/interfaces/jdbc/org/postgresql/DriverClass.java
? src/interfaces/libpgeasy/Makefile
? src/interfaces/libpgeasy/libpgeasy.so.2.1
? src/interfaces/libpgtcl/Makefile
? src/interfaces/libpgtcl/libpgtcl.so.2.1
? src/interfaces/libpq/Makefile
? src/interfaces/libpq/libpq.so.2.1
? src/interfaces/libpq++/Makefile
? src/interfaces/libpq++/libpq++.so.3.1
? src/interfaces/odbc/GNUmakefile
? src/interfaces/odbc/Makefile.global
? src/interfaces/perl5/blib
? src/interfaces/perl5/Makefile
? src/interfaces/perl5/pm_to_blib
? src/interfaces/perl5/Pg.c
? src/interfaces/perl5/Pg.bs
? src/interfaces/python/tutorial/pgtools.pyc
? src/interfaces/python/tutorial/basics.pyc
? src/pl/plpgsql/src/Makefile
? src/pl/plpgsql/src/mklang.sql
? src/pl/plpgsql/src/libplpgsql.so.1.0
? src/pl/tcl/mkMakefile.tcldefs.sh
? src/pl/tcl/Makefile.tcldefs
? src/test/regress/GNUmakefile
Index: src/backend/commands/async.c
===
RCS file: /usr/local/cvsroot/pgsql/src/backend/commands/async.c,v
retrieving revision 1.59
diff -c -r1.59 async.c
*** src/backend/commands/async.c2000/04/12 17:14:57 1.59
--- src/backend/commands/async.c2000/05/14 02:35:09
***
*** 349,356
--- 349,365
sRel = heap_beginscan(lRel, 0, SnapshotNow, 1, key);
while (HeapTupleIsValid(lTuple = heap_getnext(sRel, 0)))
+ {
heap_delete(lRel, &lTuple->t_self, NULL);
[BUGS] minor bug: unlisten
I looked at the TODO before sending this, and found nothing regarding listen/unlisten. I was unable to find the bug report sumission page at www.postgresql.org, even though it was mentioned in this template. Your name : Jeff Davis Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel Pentium Operating System (example: Linux 2.0.26 ELF) : Linux ELF (RedHat 6.2) PostgreSQL version (example: PostgreSQL-6.5.1): PostgreSQL-7.0 Compiler used (example: gcc 2.8.0) : gcc 2.91.66 Please enter a FULL description of your problem: Regarding UNLISTEN: 'UNLISTEN ' does not remove LISTEN entries for '' in 'pg_listener' class, nor does it prevent NOTIFYication. However, note that 'UNLISTEN *' does remove these entries, and prevent NOTIFYication, as it should. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- A full transcript (from 'psql' client) that demonstrates this follows: test=# listen test; LISTEN test=# notify test; NOTIFY Asynchronous NOTIFY 'test' from backend with pid '17457' received. test=# unlisten test; UNLISTEN test=# notify test; NOTIFY Asynchronous NOTIFY 'test' from backend with pid '17457' received. test=# unlisten *; UNLISTEN test=# notify test; NOTIFY test=# End of transcript. I tried this on two seperate machines, and it was the same. They are almost identical in hardware, software, and configuration. Perhaps you could also execute a query such as 'SELECT * FROM pg_listener', so as to view table status at various points during the aforementioned procedure. This has been omitted due to report lenth concerns. If you know how this problem might be fixed, list the solution below: - If 'unlisten ' were aliased to the query "DELETE FROM pg_listener WHERE relname=''," which works just fine, it would appear to solve the problem, however I am not aware of performance issues with this implementation, nor am I aware how the current 'UNLISTEN' query is implemented. Thank you, Jeff Davis __ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/
Re: [BUGS] Initdb Bug
Tom Lane writes: > Or possibly he's invoking the right initdb, but it's finding the wrong > postgres binary. Or the wrong template files? Run initdb --show to see. > I wonder if we can get initdb to check that it's > invoking the right version of 'postgres'? A display of the version > number wouldn't be a bad idea either. I know I might have had a different opinion on this before but I'm beginning to think that the path to any auxiliary programs needs to be substituted into the script at build time. There's plenty of precedent for this technique and there's probably very little reason to run a given initdb with a different backend, and even if there is you'd need to go out of your way anyhow. On the other hand, the amount of gratuitous problems of the sort under consideration here should go to zero. For 7.1 I'm hoping to get the --program-suffix like configure options working, so the current scheme is going to blow up anyway. Something to think about maybe. -- Peter Eisentraut Sernanders väg 10:115 [EMAIL PROTECTED] 75262 Uppsala http://yi.org/peter-e/Sweden
Re: [BUGS] regression test fails on AIX
Rainer Tammer writes: > The regression test fails on a couple of topics. > -> HINT --enable-locale !! You need to unset all your locale settings before running the tests. (any or all of LC_*, LOCALE, LANG, LANGUAGES, etc.) -- Peter Eisentraut Sernanders väg 10:115 [EMAIL PROTECTED] 75262 Uppsala http://yi.org/peter-e/Sweden
Re: [BUGS] Initdb Bug
> [Charset ISO-8859-1 unsupported, filtering to ASCII...] > > Tom Lane writes: > > > > > Or possibly he's invoking the right initdb, but it's finding the wrong > > > postgres binary. > > > > Or the wrong template files? Run initdb --show to see. > > > > > I wonder if we can get initdb to check that it's > > > invoking the right version of 'postgres'? A display of the version > > > number wouldn't be a bad idea either. > > > > I know I might have had a different opinion on this before but I'm > > beginning to think that the path to any auxiliary programs needs to be > > I understand your concern. My question is how does someone access > initdb without getting binaries of the same version? > > Seems it may be happening, but how? > This happened to me in v6.5.3, and the problem was/is that the path setting in the install instructions is incorrect. In the INSTALL file that came with v6.5.3: Step 17, line 441: PATH=$PATH:/usr/local/pgsql/bin is no good (at least for RH6.0, 6.1, shell=bash). RH's default install of postgres puts the binaries in /usr/bin, which is then ahead of /usr/local/pgsql/bin in the path. Thus, the newly created binaries aren't found. The line should be: PATH=/usr/local/pgsql/bin:$PATH I'm sorry I didn't file a bug report after I figured it out, but since I've got finals I should be studying for, now seems like a good time ;) Tucker
