Re: [HACKERS] CSV arm check failure
Am Donnerstag, 6. Januar 2005 17:39 schrieb Jim Buttafuoco: I couldn't get 2.4.27 to patch with the arm patches, so I downloaded 2.4.25 (with has CONFIG_FPE_NWFPE=y) and ALL tests passed. OK, that's good enough. At least we found the cause of the problem. Future generations can look in the archives if they are interested in that kind of detail. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Porting/platforms/buildfarm open issues
Am Donnerstag, 6. Januar 2005 16:30 schrieb Honda Shigehiro: 2) mkdir? Due to odd behavior of 'mkdir -p' command, I got below error when 'make install': mkdir -p -- /usr/local/pgsql/bin /usr/local/pgsql/share mkdir: cannot create /usr/local/pgsql/share. /usr/local/pgsql/share: File exists make[2]: *** [installdirs] Error 2 Would you place the attached version of mkinstalldirs in the config/ directory in the PostgreSQL source tree and try installing again? (Of course, you might need to delete /usr/local/pgsql first to have the same preconditions.) Please report whether it works better. -- Peter Eisentraut http://developer.postgresql.org/~petere/ mkinstalldirs.bz2 Description: BZip2 compressed data ---(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
Re: [PATCHES] [HACKERS] Bgwriter behavior
On Fri, 7 Jan 2005, Bruce Momjian wrote: Do we want to add this additional log infor to CVS for 8.0? No, unless we're looking for an RC5? --- Simon Riggs wrote: On Mon, 2005-01-03 at 19:14 -0500, Bruce Momjian wrote: Simon Riggs wrote: Here's my bgwriter instrumentation patch, which gives info that could allow the bgwriter settings to be tuned. Uh, what does this do exactly? Add additional logging output? Produces output like this... DEBUG:ARC T1target= 45 B1len= 4954 T1len= 40 T2len= 4960 B2len= 46 DEBUG:ARC total = 98% B1hit= 0% T1hit= 0% T2hit= 98% B2hit= 0% DEBUG:ARC buffer dirty misses= 22% (wasted=0); cleaned= 4494 when you have debug_shared_buffers (= n) set and you have server messages DEBUG1 available. The last line of log output has been replaced by this version. -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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]) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] PostgreSQL 8.0.0 Release Scheduale
Michael Glaesemann wrote: Having the release earlier in the week also means there will probably be more people online to quickly respond to any issues that arise with the release. Then again, it also means its more likely more people will be exposed to any such issues as well. Weighing the two, I'd think former is preferable to the latter. (Not that there'll be any issues anyway :) The spirit of the expression Friday afternoon car translated to Swedish would be captured by Måndagsexemplar (made on a monday), since we consider things made on Mondays to have a particular bad quality. Don't know why really, perhaps we've forgotten that weekends are for rest and recreation :-) Regards, Thomas Hallgren ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Porting/platforms/buildfarm open issues
Hello, This installdirs are worked well. 'make install' succeeds without modifying Makefiles. Thank you. regards, -- Shigehiro Honda From: Peter Eisentraut [EMAIL PROTECTED] Subject: Re: [HACKERS] Porting/platforms/buildfarm open issues Date: Fri, 7 Jan 2005 10:53:56 +0100 Am Donnerstag, 6. Januar 2005 16:30 schrieb Honda Shigehiro: 2) mkdir? Due to odd behavior of 'mkdir -p' command, I got below error when 'make install': mkdir -p -- /usr/local/pgsql/bin /usr/local/pgsql/share mkdir: cannot create /usr/local/pgsql/share. /usr/local/pgsql/share: File exists make[2]: *** [installdirs] Error 2 Would you place the attached version of mkinstalldirs in the config/ directory in the PostgreSQL source tree and try installing again? (Of course, you might need to delete /usr/local/pgsql first to have the same preconditions.) Please report whether it works better. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] typeoid by name for PG72
Hello, I'm trying to make an array constructor function work for PGSQL from 72 to 80. My current problem is that in PG73 the ArrayType structure wants an elementtype but FmgrInfo does not contain the Oid of the given argument (only of the function). Is there an easy way to either: - obtain OID of a given argument - obtain OID of a given type by its name By easy I mean not involving a query to the backend. --strk; For standing up against patentability of software, Thank You, Poland! Read the intervention:http://kwiki.ffii.org/ConsPolon041221En Send your thanks: thankyoupoland.info Read/do more: http://www.noepatents.org/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [Testperf-general] pg_autovacuum w/ dbt2
I'm curious, the original run you posted with 3825 NOTPM is still 17% faster than the latest pg_autovacuum run which shows 3280 NOTPM. Is this on the same hardware? Also, did the original non-pg_autovacuum run any manual vacuum commands? Also, does the non-pg_autovacuum run start slowing down after a while? The graphs look like there is a slight decline in performance as time goes on, what happens if you double the length of the test? Thanks for doing the testing! Matthew Mark Wong wrote: I apologize for the significant delay, here's a link to results to a test with 8.0rc3: http://www.osdl.org/projects/dbt2dev/results/dev4-010/236/ These are the same parameters with as run 215, listed below with the but with --enable-debug --enable-cassert. I also ran pg_autovacuum with -d4, where the output can be seen here: http://www.osdl.org/projects/dbt2dev/results/dev4-010/236/dbt2.out I, uh, wasn't able to reproduce the previous errors after repairing my filesystems after a power outage. So I figure that might be good news. The performance is up from run 215 with the errors, so I'll continue with trying to tune some of the pg_autovacuum values. Mark On Tue, Dec 21, 2004 at 09:41:31AM -0800, Mark Wong wrote: After all this time I finally got around to vacuuming the database with dbt2 with pg_autovacuum. :) http://www.osdl.org/projects/dbt2dev/results/dev4-010/215/ Doesn't look so good though, probably because I'm not using optimal settings with pg_autovacuum. So far I have only tried the default settings (running without any arguments, except -D). The only thing that's peculiar is a number of unexpected rollbacks across all of the transactions. I suspect it was something to do with these messages coming from pg_autovacuum: [2004-12-20 15:48:18 PST] ERROR: Can not refresh statistics information from the database dbt2. [2004-12-20 15:48:18 PST] The error is [ERROR: failed to re-find parent key in pk_district ] This is with 8.0rc1. I can get rc2 installed since it just came out. So let me know what I can try and what not. Mark ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Porting/platforms/buildfarm open issues
Am Freitag, 7. Januar 2005 13:10 schrieb Honda Shigehiro: This installdirs are worked well. 'make install' succeeds without modifying Makefiles. Does anyone object to installing the new mkinstalldirs? I took the latest version from the automake CVS. The important change was apparently to use mkdir -p only with GNU mkdir. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Bgwriter behavior
Marc G. Fournier [EMAIL PROTECTED] writes: On Fri, 7 Jan 2005, Bruce Momjian wrote: Do we want to add this additional log infor to CVS for 8.0? No, unless we're looking for an RC5? I vote no as well. While it's probably not a dangerous change, the need for it has not been demonstrated. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] PostgreSQL 8.0.0 Release Scheduale
Marc G. Fournier [EMAIL PROTECTED] writes: On Thu, 6 Jan 2005, Bruce Momjian wrote: I agree Magnus has a point here. We just did major changes for Win32 configuration file locations and it seems it is a mistake to not have sufficient time for testing and to see if something else comes up. I think we should shoot for the end of next week. I'm the last person to argue against delaying to get it right :) But, if we are going to delay to end of week, why not just make it a Sun package, Mon release, so that Josh et al can get the best bang for the PR/release announcement? I think those were actually quite minor changes and are already fully tested ;-). I see no need to slip a week for it. If there had been significant changes between RC3 and RC4 then I would agree we need a full week; but in practice the testing that was done on RC3 counts too. So I think we are fine with release next week rather than the week after. And I for one want to get this sucker out the door... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Compiere ERP and SQL quirks
Hello We made Compiere (Open source ERP system) to Firebird (Fyracle) This is special version of Firebird with added Oracle compatibility (Oracle PL/SQL). It made porting much easier, but our experience show that it would be now also not very difficult with other databases like PostgreSQL. Compiere contained lot of PL/SQL which size is now largely reduced. Main problem is some SQL constructions which are not supported. Particulary something like this is very important: UPDATE sometable set (col1,col2) = (select col_a,col_b from another_table where ) This construction seems to be quite useful in another cases. Would be it diffcult and possible to add such syntax to PostgreSQL ? Marek Mosiewicz http://www.jotel.com.pl ---(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] Porting/platforms/buildfarm open issues
Peter Eisentraut [EMAIL PROTECTED] writes: Am Freitag, 7. Januar 2005 17:20 schrieb Tom Lane: Could you post a diff against what we have now? Attached. Looks ok to me. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Compiere ERP and SQL quirks
Marek Mosiewicz wrote: Hello We made Compiere (Open source ERP system) to Firebird (Fyracle) This is special version of Firebird with added Oracle compatibility (Oracle PL/SQL). It made porting much easier, but our experience show that it would be now also not very difficult with other databases like PostgreSQL. Compiere contained lot of PL/SQL which size is now largely reduced. Main problem is some SQL constructions which are not supported. Particulary something like this is very important: UPDATE sometable set (col1,col2) = (select col_a,col_b from another_table where ) This construction seems to be quite useful in another cases. Would be it diffcult and possible to add such syntax to PostgreSQL ? PostgreSQL has limited support for the SQL 92 row constructor. You can use it in select expressions in most places, but not in update as you noticed. Be forewarned that row constructor expressions involving the or operators can give the wrong answer: select (2,2,3) (2,1,3) returns false when it should return true. Merlin ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [Testperf-general] pg_autovacuum w/ dbt2
Ok, but what I'm curious to do is see if you run the non-pg_autovacuum test for a long time (4 hours? more?) when does it get slower that running with pg_autovacuum. And, can you demonstrate that running the tests with pg_autovacuum for a long time (say 4 hours) that the performance stays steady. Also, I would very much like to see this test run with pg_autovacuum and it's vacuum delay settings enabled. Matthew ps: I know time is limited and these tests take a lot of time to run, so please take my requests with a grain of salt, all I'm saying is that I think these would be interesting results to see. Mark Wong wrote: Yeah, same hardware and database configuration. No manual vacuum commands before. The decline in performance has been pretty consistent in all my previous tests and people have told me on many occasions that the decline in performance was probably because I was never using vacuum... Mark On Fri, Jan 07, 2005 at 08:48:52AM -0500, Matthew T. O'Connor wrote: I'm curious, the original run you posted with 3825 NOTPM is still 17% faster than the latest pg_autovacuum run which shows 3280 NOTPM. Is this on the same hardware? Also, did the original non-pg_autovacuum run any manual vacuum commands? Also, does the non-pg_autovacuum run start slowing down after a while? The graphs look like there is a slight decline in performance as time goes on, what happens if you double the length of the test? Thanks for doing the testing! Matthew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [Testperf-general] pg_autovacuum w/ dbt2
Mark, No manual vacuum commands before. The decline in performance has been pretty consistent in all my previous tests and people have told me on many occasions that the decline in performance was probably because I was never using vacuum... Hmmm ... what autovacuum params are you using? From the look of the graphs, VACUUM is running every 6 minutes or so, and having a huge impact on performance when it does run. Give me a bit of time to crunch the database log, and we'll see which table vacuums were taking the most time. Can you re-run this test with a fairly generous vacuum_delay setting? Given that the performance drops seem to correspond to wait times, I think this could mean a big difference. -- Josh Berkus Aglio Database Solutions San Francisco ---(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
Re: [HACKERS] [Testperf-general] pg_autovacuum w/ dbt2
On Fri, Jan 07, 2005 at 09:58:47AM -0800, Josh Berkus wrote: Mark, No manual vacuum commands before. The decline in performance has been pretty consistent in all my previous tests and people have told me on many occasions that the decline in performance was probably because I was never using vacuum... Hmmm ... what autovacuum params are you using? From the look of the graphs, VACUUM is running every 6 minutes or so, and having a huge impact on performance when it does run. Give me a bit of time to crunch the database log, and we'll see which table vacuums were taking the most time. Can you re-run this test with a fairly generous vacuum_delay setting? Given that the performance drops seem to correspond to wait times, I think this could mean a big difference. All default parameters. Matthew also recommended using the vacuum_delay setting so I was about to try that. Mark ---(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] Compiere ERP and SQL quirks
Upps sorry now found it on TODO list. I was not aware that it is SQL92 standard. Is it difficult to implement ? Simplest approach would be to rewrite it to UPDATE t1 set col1 = (select cola ...), col2 = (select colb) but it would result in not optimal plan. Marek Mosiewicz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Merlin Moncure Sent: Friday, January 07, 2005 6:15 PM To: Marek Mosiewicz Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Compiere ERP and SQL quirks Marek Mosiewicz wrote: Hello We made Compiere (Open source ERP system) to Firebird (Fyracle) This is special version of Firebird with added Oracle compatibility (Oracle PL/SQL). It made porting much easier, but our experience show that it would be now also not very difficult with other databases like PostgreSQL. Compiere contained lot of PL/SQL which size is now largely reduced. Main problem is some SQL constructions which are not supported. Particulary something like this is very important: UPDATE sometable set (col1,col2) = (select col_a,col_b from another_table where ) This construction seems to be quite useful in another cases. Would be it diffcult and possible to add such syntax to PostgreSQL ? PostgreSQL has limited support for the SQL 92 row constructor. You can use it in select expressions in most places, but not in update as you noticed. Be forewarned that row constructor expressions involving the or operators can give the wrong answer: select (2,2,3) (2,1,3) returns false when it should return true. Merlin ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(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
Re: [HACKERS] [Testperf-general] pg_autovacuum w/ dbt2
Mark, All default parameters. Matthew also recommended using the vacuum_delay setting so I was about to try that. Interesting ... the default parameters are quite conservative, running only when the table has doubled in new rows. So if those spikes are vacuums, then the DBT2 test is updating or adding 100% of the rows in the orders table every 6-8 minutes?Does that seem right? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-ru-general] [HACKERS] Final call for translation updates
Hi there, I just completed russian translation of .po files ( except ru.po for backend ). diff against rc3 is available from http://www.sai.msu.su/~megera/postgres/docs/ru.po-8.0.0.rc3.diff.gz Oleg On Thu, 6 Jan 2005, Serguei Mokhov wrote: - Original Message - From: Peter Eisentraut [EMAIL PROTECTED] Sent: January 06, 2005 3:48 AM Am Mittwoch, 5. Januar 2005 05:38 schrieb Oleg Bartunov: Serguei, I have translations (I didn't touch libpq, psql in work, other files seems complete) available from http://www.sai.msu.su/~megera/oddmuse/ Let me know when you have something finished and ready to commit. Will be in soon. -s Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Compiere ERP and SQL quirks
Marek Mosiewicz wrote: Upps sorry now found it on TODO list. I was not aware that it is SQL92 standard. Is it difficult to implement ? Simplest approach would be to rewrite it to UPDATE t1 set col1 = (select cola ...), col2 = (select colb) but it would result in not optimal plan. Doesn't something like UPDATE t1 SET col1=cola, col2=colb FROM t1 JOIN anothertable ot ON t1.id=ot.id WHERE ... Work the way you'd like it? I'd expect this syntax to be as widely portable and performant. Regards, Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [Testperf-general] pg_autovacuum w/ dbt2
On Fri, Jan 07, 2005 at 10:13:52AM -0800, Josh Berkus wrote: Mark, All default parameters. Matthew also recommended using the vacuum_delay setting so I was about to try that. Interesting ... the default parameters are quite conservative, running only when the table has doubled in new rows. So if those spikes are vacuums, then the DBT2 test is updating or adding 100% of the rows in the orders table every 6-8 minutes?Does that seem right? Some hand-wavey math here: We start with 18,000,000 rows in the orders table. Based one 3281 transactions per minute for just the new-order transaction: 288 transactions per minute for delivery New-order inserts 3281 rows per minute (not counting the 1% of rollbacks.) Delivery updates 288 rows per minute in orders. So no, we're not change that many rows per minute... Mark ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Compiere ERP and SQL quirks
On Fri, 7 Jan 2005, Merlin Moncure wrote:
Marek Mosiewicz wrote:
Hello
We made Compiere (Open source ERP system) to Firebird (Fyracle)
This is special version of Firebird with added Oracle compatibility
(Oracle
PL/SQL).
It made porting much easier, but our experience show that it
would be now also not very difficult with other databases like
PostgreSQL.
Compiere contained lot of PL/SQL which size is now largely reduced.
Main problem is some SQL constructions which are not supported.
Particulary something like this is very important:
UPDATE sometable set (col1,col2) = (select col_a,col_b from
another_table
where )
This construction seems to be quite useful in another cases.
Would be it diffcult and possible to add such syntax to PostgreSQL ?
PostgreSQL has limited support for the SQL 92 row constructor. You can
use it in select expressions in most places, but not in update as you
noticed.
Umm, SQL92 doesn't appear to allow row constructors at that place in
update as far as I can tell.
set clause list ::=
set clause [ { comma set clause }... ]
set clause ::=
object column equals operator update source
update source ::=
value expression
| null specification
| DEFAULT
object column ::= column name
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[HACKERS] Libtool?
Various recent and not so recent problem reports got me thinking again that it might be worth switching our shared library build system to libtool. Among those are: - Guesswork about which spellings of -rpath, -export-dynamic, -fpic etc. work on a particular platform or compiler. - Lack of information about which libraries libpq depends on. - Makefile.shlib can only build one library per directory. - pgxs is pretty ugly and inflexible because of the above. - Static libraries built with -fpic, which is sometimes considered a bug. - Misbehavior with rpaths pointing the wrong way during the regression tests and similar problems could maybe be tackled. Considering that pretty much everyone uses libtool these days, I'm not too worried about portability. (And before anyone asks: No, libtool does not require automake.) I think it may be worth trying out. Comments? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Compiere ERP and SQL quirks
Merlin Moncure wrote: Andreas wrote: Doesn't something like UPDATE t1 SET col1=cola, col2=colb FROM t1 JOIN anothertable ot ON t1.id=ot.id WHERE ... Work the way you'd like it? I'd expect this syntax to be as widely portable and performant. Hmm, 'from' in an update is a PostgreSQL extension to the update command :). Ooops... Oracle doesn't know it, I used to use it on MSSQL. Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] Bgwriter behavior
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: On Fri, 7 Jan 2005, Bruce Momjian wrote: Do we want to add this additional log infor to CVS for 8.0? No, unless we're looking for an RC5? I vote no as well. While it's probably not a dangerous change, the need for it has not been demonstrated. OK, Simon, would you email me a copy of the patch again privately so I can put it in the 8.1 queue. I seem to have lost the email. Thanks. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 8: explain analyze is your friend
Re: [HACKERS] [Testperf-general] pg_autovacuum w/ dbt2
Mark Wong wrote: On Fri, Jan 07, 2005 at 10:13:52AM -0800, Josh Berkus wrote: Mark, All default parameters. Matthew also recommended using the vacuum_delay setting so I was about to try that. Interesting ... the default parameters are quite conservative, running only when the table has doubled in new rows. So if those spikes are vacuums, then the DBT2 test is updating or adding 100% of the rows in the orders table every 6-8 minutes?Does that seem right? Some hand-wavey math here: We start with 18,000,000 rows in the orders table. Based one 3281 transactions per minute for just the new-order transaction: 288 transactions per minute for delivery New-order inserts 3281 rows per minute (not counting the 1% of rollbacks.) Delivery updates 288 rows per minute in orders. So no, we're not change that many rows per minute... Except the thing pg_autovacuum is actually doing is Analyzing the district table (4800 rows, takes ~15 sec) and vacuuming the warehouse table (66,000, takes ~50sec) which takes about 50 seconds. Since the default vacuum sleep time is 5 minutes, that would explain the dip every 6 minutes. Matthew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Libtool?
On Fri, 7 Jan 2005, Peter Eisentraut wrote: Various recent and not so recent problem reports got me thinking again that it might be worth switching our shared library build system to libtool. Among those are: - Guesswork about which spellings of -rpath, -export-dynamic, -fpic etc. work on a particular platform or compiler. - Lack of information about which libraries libpq depends on. - Makefile.shlib can only build one library per directory. - pgxs is pretty ugly and inflexible because of the above. - Static libraries built with -fpic, which is sometimes considered a bug. - Misbehavior with rpaths pointing the wrong way during the regression tests and similar problems could maybe be tackled. Considering that pretty much everyone uses libtool these days, I'm not too worried about portability. (And before anyone asks: No, libtool does not require automake.) I think it may be worth trying out. Comments? Does it work with Windows, or with that be a 'special case'? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Developing win32 admin tool for Postgresql 8 and have run into a problem
Hi, If this is not the appropriate list I apologize. Anyway, I am using Borland Delphi 7 and Zeoslib PG access components and I have just noticed that when I restore a database from 7.x and then load the function source into my program and make a change, i.e. compile it, the next time I open it the all the carriage return line feeds are gone, it's just one big string. The function continues to work, but is a pain to edit. I saved it in my app and then opened using PG admin and normally you can see the CRLFs in the property view, but they are totally gone. This did work fine when my test servers where on 7.4.x. I even converted all the CRLF to LF and that also failed. If I do a brand new function on 8.0 I don't have any problems, the CRLF stay. If anyone has any idea why this would be happening on 8.0 and not on 7.x please let me know, I know you are all busy with the 8.0 release so I will understand if no one replies. Thanks, Tony Caduto AM Software Design http://www.amsoftwaredesign.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] subqueries in check
Hi, i was looking at the unsuported features in the RC4 docs and found this: F671| Enhanced integrity management| Subqueries in CHECK| intentionally omitted Why is it *intentionally omitted*? Is it to hard? or has some side-effects? just a question! regards, Jaime Casanova _ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com ---(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
