Re: [HACKERS] docs toolchain appears broke?
Tom Lane <[EMAIL PROTECTED]> writes: > Larry Rosenman <[EMAIL PROTECTED]> writes: > > gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/doc/src/sgml' > > cd sgml && tar -cf ../programmer.tar --exclude=Makefile > > --exclude='*.sgml' --exclude=ref *.html -C `cd . && pwd`/graphics > > catalogs.gif connections.gif > > tar: can't add file catalogs.gif : No such file or directory > > tar: can't add file connections.gif : No such file or directory > > gmake: *** [programmer.tar] Error 1 > > Kinda looks like Ian broke the compile-in-source-dir case while > making the compile-in-separate-dir case work. Tut tut. Yes. My apologies. This patch is one way to fix things. Ian Index: Makefile === RCS file: /home/projects/pgsql/cvsroot/pgsql/doc/src/Makefile,v retrieving revision 1.17 diff -u -r1.17 Makefile --- Makefile2001/03/25 08:32:24 1.17 +++ Makefile2001/03/26 07:03:23 @@ -43,17 +43,20 @@ programmer.tar: $(MAKE) -C sgml clean $(MAKE) -C sgml programmer.html - cd sgml && $(TAR) -cf ../$@ $(TAREXCLUDE) *.html -C `cd $(srcdir) && pwd`/graphics catalogs.gif connections.gif + abssrcdir=`cd $(srcdir) && pwd`; \ + cd sgml && $(TAR) -cf ../$@ $(TAREXCLUDE) *.html -C $$abssrcdir/graphics +catalogs.gif connections.gif tutorial.tar: $(MAKE) -C sgml clean $(MAKE) -C sgml tutorial.html - cd sgml && $(TAR) -cf ../$@ $(TAREXCLUDE) *.html -C `cd $(srcdir) && pwd`/graphics clientserver.gif + abssrcdir=`cd $(srcdir) && pwd`; \ + cd sgml && $(TAR) -cf ../$@ $(TAREXCLUDE) *.html -C $$abssrcdir/graphics +clientserver.gif postgres.tar: $(MAKE) -C sgml clean $(MAKE) -C sgml postgres.html - cd sgml && $(TAR) -cf ../$@ $(TAREXCLUDE) *.html -C `cd $(srcdir) && pwd`/graphics catalogs.gif clientserver.gif connections.gif + abssrcdir=`cd $(srcdir) && pwd`; \ + cd sgml && $(TAR) -cf ../$@ $(TAREXCLUDE) *.html -C $$abssrcdir/graphics +catalogs.gif clientserver.gif connections.gif man.tar: $(MAKE) -C sgml man ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Call for platforms
Two more for the list (not a single regression test failing, which is a first on Alpha!) Tru64 4.0G Alpha cc-v6.3-129 7.1 2001-03-28 Tru64 4.0G Alpha gcc-2.95.1 7.1 2001-03-28 I updated the regression test database as well. Adriaan ---(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] docs toolchain appears broke?
Larry Rosenman <[EMAIL PROTECTED]> writes: > gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/doc/src/sgml' > cd sgml && tar -cf ../programmer.tar --exclude=Makefile > --exclude='*.sgml' --exclude=ref *.html -C `cd . && pwd`/graphics > catalogs.gif connections.gif > tar: can't add file catalogs.gif : No such file or directory > tar: can't add file connections.gif : No such file or directory > gmake: *** [programmer.tar] Error 1 Kinda looks like Ian broke the compile-in-source-dir case while making the compile-in-separate-dir case work. Tut tut. regards, tom lane ---(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] Random make check failures
Steve Nicolai <[EMAIL PROTECTED]> writes: > I'm seeing random failures in the parallel tests run by > "make check". Sometimes (40% or so) all tests will succeed. > The rest of the time, I will get one or more failures. > The specific failures are connection failures: > ! psql: connectDBStart() -- connect() failed: Connection refused > ! Is the postmaster running locally > ! and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? > I'm running on Solaris 8, with the 2nd update installed. We've heard reports that this goes away if you tweak the pg_regress script to use TCP rather than Unix-socket connections (look for the bit that forces unix_sockets=no). Nobody seems to have any idea why Solaris has a problem with Unix-socket connections ... 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: [HACKERS] Re: Vaccuum Failure w/7.1beta4 on Linux/Sparc -- FALSE ALARM
Ryan Kirkpatrick <[EMAIL PROTECTED]> writes: > On Mon, 12 Mar 2001, Ryan Kirkpatrick wrote: >> While testing some existing database applications on 7.1beta4 on >> my Sparc 20 running Debian GNU/Linux 2.2, I got the following error on >> attempting to do a vacuum of a table: >> >> NOTICE: FlushRelationBuffers(jobs, 1399): block 953 is referenced (private 0, >global 1) >> ERROR! Can't vacuum table Jobs! ERROR: VACUUM (repair_frag): FlushRelationBuffers >returned -2 This is probably explained by the problem we found a few days ago with BufferSync acquiring locks it shouldn't. regards, tom lane ---(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] Call for platforms
On Wed, 21 Mar 2001, Thomas Lockhart wrote: > OK, here is my current platform list taken from the -hackers list and > from Vince's web page. I'm sure I've missed at least a few reports, but > please confirm that platforms are actually running and passing > regression tests with recent betas or the latest release candidate. Updates... > Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick Tested RC1 with 2.2.17 on my XLT366 Alpha, all regression tests passed. > Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick Tested RC1 with 2.2.18 on my Sparc 20 (SM51), all regression tests passed. Both have been entered into the regression database on the website as well. TTYL. --- | "For to me to live is Christ, and to die is gain."| |--- Philippians 1:21 (KJV) | --- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | --- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Random make check failures
I'm seeing random failures in the parallel tests run by "make check". Sometimes (40% or so) all tests will succeed. The rest of the time, I will get one or more failures. The specific failures are connection failures: ! psql: connectDBStart() -- connect() failed: Connection refused ! Is the postmaster running locally ! and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? I tried running pg_regress with --debug to see if it would shed some light on the matter. I didn't see anything in the output indicating what was failing on the backend. I'm running on Solaris 8, with the 2nd update installed. I'm new to postgresql, could someone with some experience give me a few pointers on tracking this one down? Steve Nicolai ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Call for platforms
-BEGIN PGP SIGNED MESSAGE- On 25 Mar 2001, at 15:02, Tom Lane wrote: > > (rounding on the final digit) and this rather troubling output from > > type_sanity. > > Most bizarre --- and definitely indicative of trouble. Would you send > along the output of this query in that database: > > select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval > from pg_attribute p1, pg_class p2 > where atttypid = 27 and p2.oid = attrelid > order by 1; I was afraid of that ;) Here's the output: [PostgreSQL 7.1beta6 on armv4l-unknown-linux-gnuoldld, compiled by GCC 2.95.1] type \? for help on slash commands type \q to quit type \g or terminate with semicolon to execute query You are currently connected to the database: postgres postgres=> select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval from pg_attribute p1, pg_class p2 where atttypid = 27 and p2.oid = attrelid order by 1; oid|attrelid|relname |attname|attlen|attalign|attbyval - -++--+---+--++ 16401|1247|pg_type |ctid | 6|i |f 16415|1262|pg_database |ctid | 6|i |f 16439|1255|pg_proc |ctid | 6|i |f 16454|1260|pg_shadow |ctid | 6|i |f 16464|1261|pg_group |ctid | 6|i |f 16486|1249|pg_attribute |ctid | 6|i |f 16515|1259|pg_class |ctid | 6|i |f 16526|1215|pg_attrdef|ctid | 6|i |f 16537|1216|pg_relcheck |ctid | 6|i |f 16557|1219|pg_trigger|ctid | 6|i |f 16572| 16567|pg_inherits |ctid | 8|i |f 16593| 16579|pg_index |ctid | 8|i |f 16610| 16600|pg_statistic |ctid | 8|i |f 16635| 16617|pg_operator |ctid | 8|i |f 16646| 16642|pg_opclass|ctid | 8|i |f 16678| 16653|pg_am |ctid | 8|i |f 16691| 16685|pg_amop |ctid | 8|i |f 16873| 16867|pg_amproc |ctid | 8|i |f 16941| 16934|pg_language |ctid | 8|i |f 16953| 16948|pg_largeobject|ctid | 8|i |f 16970| 16960|pg_aggregate |ctid | 8|i |f 17038| 17033|pg_ipl|ctid | 8|i |f 17051| 17045|pg_inheritproc|ctid | 8|i |f 17067| 17058|pg_rewrite|ctid | 8|i |f 17079| 17074|pg_listener |ctid | 8|i |f 17090| 17086|pg_description|ctid | 8|i |f 17206| 17201|pg_toast_1215 |ctid | 8|i |f 17221| 17216|pg_toast_17086|ctid | 8|i |f 17236| 17231|pg_toast_1255 |ctid | 8|i |f 17251| 17246|pg_toast_1216 |ctid | 8|i |f 17266| 17261|pg_toast_17058|ctid | 8|i |f 17281| 17276|pg_toast_16600|ctid | 8|i |f 17301| 17291|pg_user |ctid | 8|i |f 17314| 17309|pg_rules |ctid | 8|i |f 17327| 17322|pg_views |ctid | 8|i |f 17342| 17335|pg_tables |ctid | 8|i |f 17355| 17350|pg_indexes|ctid | 8|i |f (37 rows) -BEGIN PGP SIGNATURE- Version: N/A iQCVAwUBOr5XA/+IdJuhyV9xAQGfOgP6ApV6ia44bxCo/KyIE20knn/1FTysECW9 Rq9mLDhpYKHYtTWz1cgGtxzCEiRAMN+ZuO7u5nydy6TB8dp8iCd9eLAro4GAzqYM aD9V9S3nK3YwV9RaKBWJqHXNPI5enp19YS74GxN0f9VIw/4PXlYVm2tQJLVWNGs+ lFfQnraYEZQ= =Cj2l -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[Fwd: Re: [HACKERS] Call for platforms]
Hi all, Vince asked me to forward this here. Regards and best wishes, Justin Clift Original Message Subject: Re: [HACKERS] Call for platforms Date: Sun, 25 Mar 2001 19:45:37 -0500 (EST) From: Vince Vielhaber <[EMAIL PROTECTED]> To: Justin Clift <[EMAIL PROTECTED]> On Mon, 26 Mar 2001, Justin Clift wrote: > Hi Vince, > > I'm wondering if it's worth putting something on the regresssion test > results page asking people to try ALL the options if possible? > > Like, I tested Solaris 8 SPARC with './configure --p=/opt/postgresql71 > --enable-syslog', and that worked perfectly. BUT, when I started adding > in stuff like --with-openssl --with-python, there were nasty > interactions and things didn't work. > > It would be nice to know that on a Supported Platform that ALL of the > options worked (apart from the Perl option which we apparently can't > make 100% work). > > Regards and best wishes, > > Justin Clift > You might want to pass that along to hackers. It'd be interesting to hear their thoughts. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED] http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] Problems with Multibyte in 7.1 beta?
I'm trying to run the latest CVS code's regression tests and have a problem. They fail at initdb with this: Running with noclean mode on. Mistakes will not be cleaned up. /opt/home/rmager/devel/External/pgsql/src/test/regress/./tmp_check/install// usr/local/pgsql/bin/pg_encoding: erro r while loading shared libraries: /opt/home/rmager/devel/External/pgsql/src/test/regress/./tmp_check/install// usr /local/pgsql/bin/pg_encoding: undefined symbol: pg_char_to_encoding initdb: pg_encoding failed Perhaps you did not configure PostgreSQL for multibyte support or the program was not successfully installed. I ran configure with this: ./configure --enable-multibyte --enable-syslog --with-java Any ideas? --Rainer ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] docs toolchain appears broke?
Was just trying to recreate my docs from CVS, using the same tools I've been using for months, and got the following: gmake -C sgml clean gmake[1]: Entering directory `/home/ler/pg-dev/pgsql/doc/src/sgml' rm -f catalog rm -f HTML.manifest *.html rm -rf *.1 *.l man1 manl manpage.refs manpage.links manpage.log rm -f *.rtf *.tex *.dvi *.aux *.log *.ps *.pdf gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/doc/src/sgml' gmake -C sgml programmer.html gmake[1]: Entering directory `/home/ler/pg-dev/pgsql/doc/src/sgml' (echo "PUBLIC \"-//Norman Walsh//DOCUMENT DocBook HTML Stylesheet//EN\" \"/usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl\""; \ echo "PUBLIC \"-//Norman Walsh//DOCUMENT DocBook Print Stylesheet//EN\" \"/usr/local/share/sgml/docbook/dsssl/modular/print/docbook.dsl\"") > catalog jade -D . -D ./ref -D ./../graphics -d stylesheet.dsl -i output-html -t sgml book-decl.sgml programmer.sgml ln -sf programmer.html index.html gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/doc/src/sgml' cd sgml && tar -cf ../programmer.tar --exclude=Makefile --exclude='*.sgml' --exclude=ref *.html -C `cd . && pwd`/graphics catalogs.gif connections.gif tar: can't add file catalogs.gif : No such file or directory tar: can't add file connections.gif : No such file or directory gmake: *** [programmer.tar] Error 1 gmake: *** Deleting file `programmer.tar' $ this was after making a graphics directory. Did someone forget to add some files to CVS? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Vaccuum Failure w/7.1beta4 on Linux/Sparc -- FALSE ALARM
On Mon, 12 Mar 2001, Ryan Kirkpatrick wrote: > While testing some existing database applications on 7.1beta4 on > my Sparc 20 running Debian GNU/Linux 2.2, I got the following error on > attempting to do a vacuum of a table: > > NOTICE: FlushRelationBuffers(jobs, 1399): block 953 is referenced (private 0, >global 1) > ERROR! Can't vacuum table Jobs! ERROR: VACUUM (repair_frag): FlushRelationBuffers >returned -2 I moved the data directory to a local parition (from the NFS mounted one it was on) and reran my application. It worked fine this time, vaccuming tables with out errors and the above error was never seen. Looks like pgsql is not NFS safe, or at least with Linux's implementation. This is good news in that it is not a serious issue, but bad news in that now I really do have to hurry up and get more local space for this box to do anything useful with it. :) Thanks for everyone's help. TTYL. --- | "For to me to live is Christ, and to die is gain."| |--- Philippians 1:21 (KJV) | --- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | --- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] More bogus alignment assumptions
> Following up on the recent bug report from Steve Nicolai, I spent a > tedious hour groveling through all the warnings emitted by gcc with > -Wcast-align. (We ought to try to reduce the number of them, but that's > a task for another day.) > > I found seven places, in addition to the tuptoaster.c error originally > identified by Steve, in which the code is assuming that a "char foo[N]" > local variable will be aligned on better-than-char boundaries by the > compiler. All were inserted since 7.0. All but one were inserted by > Vadim in the new WAL code; the other one is in large-object support > and is my fault :-( > > I will fix these shortly, but I wanted to raise a flag to people: > don't do that. An array of X is not guaranteed to be aligned any > better than an X is. Added to TODO: * Remove warnings created by -Wcast-align -- 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]
[HACKERS] More bogus alignment assumptions
Following up on the recent bug report from Steve Nicolai, I spent a tedious hour groveling through all the warnings emitted by gcc with -Wcast-align. (We ought to try to reduce the number of them, but that's a task for another day.) I found seven places, in addition to the tuptoaster.c error originally identified by Steve, in which the code is assuming that a "char foo[N]" local variable will be aligned on better-than-char boundaries by the compiler. All were inserted since 7.0. All but one were inserted by Vadim in the new WAL code; the other one is in large-object support and is my fault :-( I will fix these shortly, but I wanted to raise a flag to people: don't do that. An array of X is not guaranteed to be aligned any better than an X is. regards, tom lane ---(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] Re: Call for platforms
Does that database have any user-created relations in it, or is it just a virgin database? It seems that the wrong attlen is being computed for ctid fields during bootstrap, but the regression test output (if it was complete) implies that the value inserted for user-created fields was OK. This doesn't make a lot of sense since it's the same code... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Escaping strings
> what's the postgresql equivalent of > > mysql_real_escape_string() > > to escape strings that are going to be passed to queries? There doesn't seem to be a function to do this in libpq, which I find slightly odd. DBD::Pg has quote() function as per usual for perl's DBI, but that's not a lot of help for C. For reference it only doubles single quote characters ' to '' and backslash characters \ to \\. What I do -- and this may not be correct, so I encourage the more knowledgeable to speak up! -- is this: 1. single quotes ' become '' (typical SQL) 2. PostgreSQL supports backslash escape sequences, so unless your input uses these protect \ as \\. 3. I translate nul, formfeed, newline, and carriage return characters to \0, \f, \n, and \r respectively. In comparison mysql_real_escape_string() omits \f but also escapes ^Z and ". For binary data probably other control characters need to be escaped as well. I'm not clear on this yet, but with TOAST in 7.1 I'm sure there'll be more interest in storing arbitary binary data. Regards, Giles ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Release Candidate 1 ...
On Fri, 23 Mar 2001, Gordon A. Runkle wrote: > In article <[EMAIL PROTECTED]>, "The > Hermit Hacker" <[EMAIL PROTECTED]> wrote: > > > > Well, its been a hard, arduous journey for this one, with several delays > > caused by the massive amount of changes that have gone into v7.1 ... > > but, tonight I've finally wrapped up Release Candidate 1 ... > > Well, done, too! I've been banging on Beta6 with data and > queries from DB2, and it's been the easiest transition I've > ever had between RDBMSs. > > Will upgrading from Beta6 to RC1 require dumping and restoring > databases? My understanding was that originally, there was a dump/reload required, but I believe that requirement was negated by a 'resetxlog' utility that Tom Lane created ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
"Mark Knox" <[EMAIL PROTECTED]> writes: >> Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox > Compiled and tested 7.1beta6 tonight. All the regression tests passed > except two - the usual minor differences in geometry (rounding on the > final digit) and this rather troubling output from type_sanity. Most bizarre --- and definitely indicative of trouble. Would you send along the output of this query in that database: select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval from pg_attribute p1, pg_class p2 where atttypid = 27 and p2.oid = attrelid order by 1; regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Release Candidate 1 ...
"Gordon A. Runkle" <[EMAIL PROTECTED]> writes: > Will upgrading from Beta6 to RC1 require dumping and restoring > databases? No, just compile and install. If you'd been on beta5 or earlier, you'd need to run contrib/pg_resetxlog to update pg_control format, but still no initdb. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Prob with regexp
Philippe Rochat writes: > I think there is a prob with regexp, which is comparing one less > character as it should. Below is an example. Result is that last > character is omitted ! A '*' means "zero or more of the preceeding character". You probably want a '+'. > > Ph.R. > > postgres=# select * from pg_database where datname ~ 'ibd01*'; > datname | datdba | encoding | datpath > -++--+- > ibd00_8 |505 |0 | ibd00_8 > ibd00_1 |505 |0 | ibd00_1 > ibd00_2 |505 |0 | ibd00_2 > ibd00_3 |505 |0 | ibd00_3 > ibd00_4 |505 |0 | ibd00_4 > ibd00_5 |505 |0 | ibd00_5 > ibd00_6 |505 |0 | ibd00_6 > ibd00_7 |505 |0 | ibd00_7 > ibd00_9 |505 |0 | ibd00_9 > ibd01_1 |505 |0 | ibd01_1 > ibd01_2 |505 |0 | ibd01_2 > ibd01_3 |505 |0 | ibd01_3 > ibd01_4 |505 |0 | ibd01_4 > ibd01_5 |505 |0 | ibd01_5 > (14 rows) > > postgres=# select * from pg_database where datname ~ 'ibd01_*'; > datname | datdba | encoding | datpath > -++--+- > ibd01_1 |505 |0 | ibd01_1 > ibd01_2 |505 |0 | ibd01_2 > ibd01_3 |505 |0 | ibd01_3 > ibd01_4 |505 |0 | ibd01_4 > ibd01_5 |505 |0 | ibd01_5 > (5 rows) > -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Prob with regexp
Philippe Rochat <[EMAIL PROTECTED]> writes: > I think there is a prob with regexp, which is comparing one less > character as it should. Below is an example. Result is that last > character is omitted ! Possibly there is a problem with your understanding of regexp patterns ... but all those matches look valid to me. See http://www.postgresql.org/devel-corner/docs/postgres/functions-matching.html for more info. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Prob with regexp
I think there is a prob with regexp, which is comparing one less character as it should. Below is an example. Result is that last character is omitted ! Ph.R. postgres=# select * from pg_database where datname ~ 'ibd01*'; datname | datdba | encoding | datpath -++--+- ibd00_8 |505 |0 | ibd00_8 ibd00_1 |505 |0 | ibd00_1 ibd00_2 |505 |0 | ibd00_2 ibd00_3 |505 |0 | ibd00_3 ibd00_4 |505 |0 | ibd00_4 ibd00_5 |505 |0 | ibd00_5 ibd00_6 |505 |0 | ibd00_6 ibd00_7 |505 |0 | ibd00_7 ibd00_9 |505 |0 | ibd00_9 ibd01_1 |505 |0 | ibd01_1 ibd01_2 |505 |0 | ibd01_2 ibd01_3 |505 |0 | ibd01_3 ibd01_4 |505 |0 | ibd01_4 ibd01_5 |505 |0 | ibd01_5 (14 rows) postgres=# select * from pg_database where datname ~ 'ibd01_*'; datname | datdba | encoding | datpath -++--+- ibd01_1 |505 |0 | ibd01_1 ibd01_2 |505 |0 | ibd01_2 ibd01_3 |505 |0 | ibd01_3 ibd01_4 |505 |0 | ibd01_4 ibd01_5 |505 |0 | ibd01_5 (5 rows) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Call for platforms
Marko Kreen writes: > OK: Linux 2.4.2 i686 / gcc 2.95.2 / Debian testing/unstable > > no problems. > > OK?: NetBSD 1.5 i586 / egcs 2.91.66 / (netbsd-1-5 from Jan) > > netbsd FAILED the geometry test, diff attached, dunno if its > critical or not. Can you check whether it matches any of the other possible geometry results? See http://www.postgresql.org/devel-corner/docs/postgres/regress-platform.html about the mechanisms. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(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] Release Candidate 1 ...
In article <[EMAIL PROTECTED]>, "The Hermit Hacker" <[EMAIL PROTECTED]> wrote: > Well, its been a hard, arduous journey for this one, with several delays > caused by the massive amount of changes that have gone into v7.1 ... > but, tonight I've finally wrapped up Release Candidate 1 ... Well, done, too! I've been banging on Beta6 with data and queries from DB2, and it's been the easiest transition I've ever had between RDBMSs. Will upgrading from Beta6 to RC1 require dumping and restoring databases? Thanks again for a great product! Gordon. -- It doesn't get any easier, you just go faster. -- Greg LeMond ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: Call for platforms
-BEGIN PGP SIGNED MESSAGE- On 22 Mar 2001, at 14:29, Thomas Lockhart wrote: > Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox Compiled and tested 7.1beta6 tonight. All the regression tests passed except two - the usual minor differences in geometry (rounding on the final digit) and this rather troubling output from type_sanity. I'm not altogether sure what impact this has. Everything seems to run just fine. *** ./expected/type_sanity.out Tue Sep 12 00:49:16 2000 - --- ./results/type_sanity.out Thu Mar 22 21:42:49 2001 *** *** 172,177 p1.attalign != p2.typalign OR p1.attbyval != p2.typbyval); oid | attname | oid | typname ! -+-+-+- ! (0 rows) - --- 172,239 p1.attalign != p2.typalign OR p1.attbyval != p2.typbyval); oid | attname | oid | typname ! ---+-+-+- ! 16572 | ctid| 27 | tid ! 16593 | ctid| 27 | tid ! 16610 | ctid| 27 | tid ! 16635 | ctid| 27 | tid ! 16646 | ctid| 27 | tid ! 16678 | ctid| 27 | tid ! 16691 | ctid| 27 | tid ! 16873 | ctid| 27 | tid ! 16941 | ctid| 27 | tid ! 16953 | ctid| 27 | tid ! 16970 | ctid| 27 | tid ! 17038 | ctid| 27 | tid ! 17051 | ctid| 27 | tid ! 17067 | ctid| 27 | tid ! 17079 | ctid| 27 | tid ! 17090 | ctid| 27 | tid ! 17206 | ctid| 27 | tid ! 17221 | ctid| 27 | tid ! 17236 | ctid| 27 | tid ! 17251 | ctid| 27 | tid ! 17266 | ctid| 27 | tid ! 17281 | ctid| 27 | tid ! 17301 | ctid| 27 | tid ! 17314 | ctid| 27 | tid ! 17327 | ctid| 27 | tid ! 17342 | ctid| 27 | tid ! 17355 | ctid| 27 | tid ! 18792 | ctid| 27 | tid ! 18820 | ctid| 27 | tid ! 18832 | ctid| 27 | tid ! 18845 | ctid| 27 | tid ! 18857 | ctid| 27 | tid ! 18869 | ctid| 27 | tid ! 1 | ctid| 27 | tid ! 18922 | ctid| 27 | tid ! 18937 | ctid| 27 | tid ! 18967 | ctid| 27 | tid ! 18990 | ctid| 27 | tid ! 19005 | ctid| 27 | tid ! 19019 | ctid| 27 | tid ! 19031 | ctid| 27 | tid ! 19042 | ctid| 27 | tid ! 19053 | ctid| 27 | tid ! 19069 | ctid| 27 | tid ! 19080 | ctid| 27 | tid ! 19103 | ctid| 27 | tid ! 20617 | ctid| 27 | tid ! 20633 | ctid| 27 | tid ! 20643 | ctid| 27 | tid ! 20655 | ctid| 27 | tid ! 20677 | ctid| 27 | tid ! 20689 | ctid| 27 | tid ! 20702 | ctid| 27 | tid ! 20716 | ctid| 27 | tid ! 20726 | ctid| 27 | tid ! 20766 | ctid| 27 | tid ! 20784 | ctid| 27 | tid ! 20794 | ctid| 27 | tid ! 20804 | ctid| 27 | tid ! 20836 | ctid| 27 | tid ! 20860 | ctid| 27 | tid ! 20879 | ctid| 27 | tid ! (62 rows) -BEGIN PGP SIGNATURE- Version: N/A iQCVAwUBOrrHrv+IdJuhyV9xAQGemgQApLVZS9xWQAtIzfgw3ILQThtEdftUBH20 FCoNqod++HunTazDwQZo6Msbunlvb8cJmSXg/kRkUmN6FQ39RtK9XEWsvFUy1+Nx eJCHiHyIMZBmmXNK1eiK0AyxFSqD8MKtgSuKvprXWNzTD4+NVZzWy9h1cONhZviN KEj9thVXQDc= =TG7n -END PGP SIGNATURE- ---(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] Re: Call for platforms
The Hermit Hacker wrote:
>
> On Thu, 22 Mar 2001, Thomas Lockhart wrote:
>
> > Solaris x867.0 2000-04-12, Marc Fournier
> >
> > scrappy, do you still have this machine?
>
> Doing tests on Solaris x86/7 right now, will report as soon as they are
> done ...
>
> > Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut
> >
> > I'll bet that someone already has Solaris covered. Report?
>
> Will do up Sparc/7 also this morning ...
In my tests on sparc/7 my compile died at line 3088 of
postgresql-7.1beta6/src/interfaces/python/pgmodule.c:
./pgmodule.c:3088: parse error before `init_pg'
That's line 3137 of today's (22Mar) snapshot, which reads:
/* Initialization function for the module */
DL_EXPORT(void)
init_pg(void)
{
I'm not a C expert by any means, but I can't figure how that is valid.
Given my ignorance, I don't want to call it a bug. Plus we don't use the
python module in production, nor the sparc platform. But it seemed worth
pointing out.
--
Karl
---(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] Re: Call for platforms
> Alexander Klimov <[EMAIL PROTECTED]> writes: >> Suddenly I obtain access to >> ULTRIX black 4.3 1 RISC > Uh ... what kind of processor is that? Offhand I don't see any > indication that any of the entries in s_lock.h are supposed to work > for Ultrix. On closer look I notice that the putative support for machines without a TEST_AND_SET implementation got broken by careless rearrangement of the declarations in s_lock.h :-(. I have repaired this, and if you update from CVS you should find that things compile. However, you don't really want to run without TEST_AND_SET support; it'll be dog-slow. Furthermore, the support for machines without TEST_AND_SET is fairly new. I doubt it existed when the Ultrix port was last reported to work. So the question above still stands. I suspect that some one of the implementations in s_lock.h was intended to be usable on Ultrix, and we've somehow dropped the declarations needed to make it go. You might want to pull down an old tarball (6.3 or before) and look at how it compiles the s_lock support on Ultrix. Please send in a patch if you find that one is necessary for s_lock support on Ultrix. 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: [HACKERS] Re: Call for platforms
Tom Lane <[EMAIL PROTECTED]> writes: > Alexander Klimov <[EMAIL PROTECTED]> writes: > > Suddenly I obtain access to > > ULTRIX black 4.3 1 RISC > > Uh ... what kind of processor is that? Offhand I don't see any > indication that any of the entries in s_lock.h are supposed to work > for Ultrix. The RISC/Ultrix machines ran (older) MIPS chips. Ultrix also ran (amazingly slowly) on the VAX architecture. [Fond memories of my first sysadmin job...] -Doug ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Call for platforms
Alexander Klimov <[EMAIL PROTECTED]> writes: > Suddenly I obtain access to > ULTRIX black 4.3 1 RISC Uh ... what kind of processor is that? Offhand I don't see any indication that any of the entries in s_lock.h are supposed to work for Ultrix. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: Call for platforms
Hi all. Suddenly I obtain access to ULTRIX black 4.3 1 RISC I don't shure is it supported, but I see /src/include/port/ultrix4.h file so my guess is `yes, at least was'. I got last version from CVS and try configure && gmake it results in gcc -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -c xlog.c -o xlog.o In file included from xlog.c:36: ../../../../src/include/storage/s_lock.h:88: warning: type defaults to `int' in declaration of `slock_t' ../../../../src/include/storage/s_lock.h:88: parse error before `*' ../../../../src/include/storage/s_lock.h:91: warning: type defaults to `int' in declaration of `slock_t' ../../../../src/include/storage/s_lock.h:91: parse error before `*' gmake[4]: *** [xlog.o] Error 1 grep of .h files shows that slock_t usualy defined in /src/include/port/*.h, but it is not defined in ultrix4.h and I can't find it in system includes. Regards, ASK ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [DOCS] Re: [HACKERS] Re: 7.1 docs
Roberto Mello <[EMAIL PROTECTED]> writes: > I like the way the Oracle functions are documented, except for the > fact that they have one huge page for all functions, which is hard on > those on slow connections reading docs online. > They have functions in tables grouped per functionality (e.g. character > functions that returning character values, character functions returning > number values) and with each function name (which is all that is in the > table) is linked to a larger explanation of the function with the complete > syntax and examples (usually two). Yes, it'd be cool to have the User's Guide contain the existing function tables with each entry hotlinked to a more extensive reference entry. We could eliminate some of the nitty-gritty details from the User's Guide that way, which I think is good. I don't want to reduce the function tables to just names a la Oracle --- I think the tables are good as they are. But there are places, such as in the discussion of the pattern-match functions, where we have reference-page-like material that doesn't fit very well in the U.G. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [DOCS] Re: [HACKERS] Re: 7.1 docs
On Sat, Mar 24, 2001 at 11:32:02AM -0500, Tom Lane wrote: > > A "page per function" approach is clearly overkill for the vast majority > of our functions. I think that's not unrelated to the fact that no one's > ever bothered to prepare such documentation ;-) Agreed. > On the other hand, the existing layout of the User's Guide encourages a > "line per function" approach, which is insufficient for at least some > functions. We've worked around that by adding paragraphs below the main > table on each page, but that seems a little awkward in many cases. Again I agree. The functions docs are insufficient for most functions I would say. I like the way the Oracle functions are documented, except for the fact that they have one huge page for all functions, which is hard on those on slow connections reading docs online. They have functions in tables grouped per functionality (e.g. character functions that returning character values, character functions returning number values) and with each function name (which is all that is in the table) is linked to a larger explanation of the function with the complete syntax and examples (usually two). http://oradoc.photo.net/ora81/DOC/server.815/a67779/function.htm#1028572 -Roberto -- +| http://fslc.usu.edu USU Free Software & GNU/Linux Club|--+ Roberto Mello - Computer Science, USU - http://www.brasileiro.net http://www.sdl.usu.edu - Space Dynamics Lab, Web Developer If it wasn't for C, we would be using BASI, PASAL and OBOL! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: Onject Database Survey ... Help needed ...
The Hermit Hacker <[EMAIL PROTECTED]> writes: > I'm just starting to go through the sections, so right now, none of them > have answers yet ... if ppl could help by reading through and providing > answers so that I can provide as accurate of information as possible, it > should give for a good initial showing for PgSQL on the Object stage ... I honestly don't make sense of some of the survey questions. On the Java Map Generation for instance, I feel the possible are answers is not close to reality at all - and there is not very much pgsql specific work in this process either... I usually have a XML representation of the schema that is transformed by XSL into SQL schema and docs. The same XML schema is then used to create the basic object model for the schema by using straight class to relation mapping. regards, Gunnar ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
