[HACKERS] Re: A more useful way to split the distribution
so it isn't a "fictitous crowd" that is going with the smaller chunks ... its about 30% on a very small sample ... (back in town from the weekend, to see the PostgreSQL tarball ripped to shreds ;) Peter, I'm with you on this. If folks want to help support PostgreSQL by providing subset-tarballs, then great. But many of us have contributed to the monolithic tarball, and will continue to do so. So lets make sure that we have *at least* the big tarball available, and if someone wants to subset it then I'm sure that would be very useful for a large number of users, even if percentage-wise they are not the majority. No point in polarizing it or forcing a choice: certainly the form we have used for the last 6 years (and for the 6 years before that too, probably) is a legitimate and useful form, and we can experiment with subsets as much as anyone cares to. With the big tarball, Lamar and others (such as Oliver and myself) can continue their packaging work for 7.1 without having to cope with last minute subset issues. - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: pg_dupp/pg_dumpall problem!
I've noticed a pg_dump/pg_dumpall problem with timestamp variables, in dumping the minute, and second values: instead of dumping 12:01:00.00 it dumps out 12:60:00.00 which is not accepted when restoring a database... You are running the Mandrake distro, or somehow compiling with a bad set of mixed-up compiler flags. You need to *not* compile with -ffast-math, but rather with -O2 or -O3 only. - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: [ANNOUNCE] PostgreSQL v7.1 Release Candidate 4
Where can I get a Postscript version docs for 7.1? I'll start building hardcopy in the next day or two, and hope that it will be done quickly (more quickly that in previous releases). Will keep y'all informed on the progress... - Thomas ---(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
AW: [HACKERS] RPM upgrade caveats going from a beta version to RC
However, 7.1beta6 to 7.1rc4 to 7.1.0 would be an ok progression, as 7.1 7.1.0, I think (saying that without having tested it could be dangerous :-)). I like this 7.1.0, it would also help to clarify what exact version is at hand. People tend to use shorthands like 7.1 to refer to any patch version (like 7.1.3). Andreas ---(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
[HACKERS] Split Distro
When I downlaod a full tarball I want it all, I'm greedy like that. ;) If it is to be split up as standard I believe problems will arise with different versions being used together (by me most likley...). Also IMHO it will not necessarily be relised the docs have not been down loaded which means refering to older docs if there was a previous installation, or not finding any if no previous install. Also to prevent confusion it might be usefull to have the split distro in its own sub directory (eg Postgresql-7.1-Split-Distro, or somesuch), as when I first looked in on the download directory it was not imediatly obvious there was one main tarball and the rest where a split version rather than a main one with optional stuff (which is not my favoured option). This is all just in my opinion of course. - Stuart ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: RPM upgrade caveats going from a beta version to RC
Oliver Elphick wrote: R = 82 b = 98 This is a very small problem of having capital R and lowercase b that I believe can be taken into account in the development of 7.2. As I suggested in another mail, let us switch to using even minor numbers for releases and odd ones for development: It's a Linux-ism that personally I don't like. You have to be familiar with the project to understand that 8.3.3 is not better for general use than 8.2.4 because 8.2 is "stable" and 8.3 is "development". -- Alessio F. Bragadini[EMAIL PROTECTED] APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-2-755750 "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925 ---(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] Split Distro
On Mon, 9 Apr 2001, Henshall, Stuart - WCP wrote: When I downlaod a full tarball I want it all, I'm greedy like that. ;) If it is to be split up as standard I believe problems will arise with different versions being used together (by me most likley...). Also IMHO it will not necessarily be relised the docs have not been down loaded which means refering to older docs if there was a previous installation, or not finding any if no previous install. Also to prevent confusion it might be usefull to have the split distro in its own sub directory (eg Postgresql-7.1-Split-Distro, or somesuch), as when I first looked in on the download directory it was not imediatly obvious there was one main tarball and the rest where a split version rather than a main one with optional stuff (which is not my favoured option). Well, unless you have a broken client, the first thing you get when you enter the directory that the files are in is: = Information regarding the split distribution In the various download directories you will find alongside files with names like postgresql-XXX.tar.gz (where XXX is a version number) smaller files with the names postgresql-base-XXX.tar.gz postgresql-opt-XXX.tar.gz postgresql-docs-XXX.tar.gz postgresql-test-XXX.tar.gz The file named "postgresql-XXX.tar.gz" is the full source distribution. Each of the other four "tarballs" contains a subset of the files from the full distribution, for downloading convenience. If you download all four of them and unpack them into the same directory you will get exactly what you would have gotten had you downloaded the full distribution. The -base package is the only one that is required for successful installation. It contains the server and the essential client interfaces. The -opt package contains all parts whose compilation needs to be enabled explicitly. This includes the C++, JDBC, ODBC, Perl, Python, and Tcl interfaces, as well as multibyte support. The -docs package contains the documentation in HTML format (man pages are in -base) and the documentation sources. You don't need to download this package if you intend to browse the documentation on the web. Finally, the -test package contains the regression test suite. (Note, this scheme is new as of version 7.1RC4. Previous versions used a different, incompatible split where all subpackages where required.) === ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostgreSQL v7.1 Release Candidate 4
Hi all, On Sun, 8 Apr 2001, The Hermit Hacker wrote: If, by Friday, April 13th, there have been no bugs reported, all that will happen is that rc4 will get renamed as the official release, no repackaging or anything ... Was hoping that I'd have some time to get around to it before now, but I haven't so am posting to the list. For quite some time I have found the behaviour of CLUSTER to be deceiving. The documentation has some to say about its short comings. The table is actually copied to a temporary table in index order, then renamed back to the original name. For this reason, all grant permissions and other indexes are lost when clustering is performed. It also drops the other relation meta data. I think this should at least be noted in the documentation for 7.1 full release or the heap copy should look at copying over triggers, checks etc. Sorry to chime in so close to release, I only just looked to see if this had been addressed. Thanks Gavin ---(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] PostgreSQL v7.1 Release Candidate 4
Bruce, Problem is the use of heap_drop_with_catalog(). * heap_drop_with_catalog - removes all record of named relation from catalogs * * 1) open relation, check for existence, etc. * 2) remove inheritance information * 3) remove indexes * 4) remove pg_class tuple * 5) remove pg_attribute tuples and related descriptions * 6) remove pg_description tuples * 7) remove pg_type tuples * 8) RemoveConstraints () * 9) unlink relation Only these things are destroyed. relchecks, for example, stays consistent and works correctly. Gavin ---(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: M68K...
I have in my posession a HP9000/433s box. It doesn't have an OS on it yet, but will probably have NetBSD 1.5 on it soon. Do we need PG tested on it? Yes! This is a 33Mhz MC68040 with 128Meg RAM... Better start now, it will take a while ;) - Thomas ---(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] --tuning compile and runtime option (?)
Justin Clift writes: When we get around to PostgreSQL's self-tuning ability being actively developed (and I think Bruce has done some of the very start with his monitor program), perhaps having a compile time option to set the default for the server, and a runtime option in case it changes? i.e. --tuning=superserver --tuning=shared --tuning=embedded postmaster -t superserver postmaster -t shared postmaster -t embedded I'm generally no friend of generic "make it fast", "make it small" options. It is usually hard to decide what settings should go under what heading because everyone is in a different situation. The solution is to provide user guidance to the existing configuration variables that goes beyond what they do by adding why the user should care. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] RPMS for RC3
Lamar Owen writes: You're still shipping old jar files. You could build them from the source package. With which JDK? As Red Hat doesn't ship a _standard_ JDK, which one is appropriate? Or, what is the _standard_ JDK? There is no standard JDK, in the same sense as there is no standard C compiler. You run configure --with-java; make; make install and voil there's the JDBC driver, made by whatever JDK was around at the moment. (For appropriate values of voil, of course.) Most distributions include Kaffe I suppose, which should serve fine (once you set up the CLASSPATH correctly; YMMV). The man pages are still in a separate tarball, or not? They're in a tarball, but they're not separate. You probably want to run gzip on the files after installation. Done automagically by the buildrootpolicy of the rpm build system, Amazing... ;-) -- 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: AW: [HACKERS] RPM upgrade caveats going from a beta version toRC
Zeugswetter Andreas SB writes: However, 7.1beta6 to 7.1rc4 to 7.1.0 would be an ok progression, as 7.1 7.1.0, I think (saying that without having tested it could be dangerous :-)). I like this 7.1.0, it would also help to clarify what exact version is at hand. People tend to use shorthands like 7.1 to refer to any patch version (like 7.1.3). I like that. In fact, we almost shipped a 7.0.0 but it was switched back at the last minute because that's how it always was. Perhaps the objection is that a 7.1.0 would indicate that there will be a 7.1.1 bug fix release, but let's not kid ourselves. -- 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
[HACKERS] timeout on lock
Hi,
i implement additional server functionality. Currently (v7.0.3), executing
SQL update statement on the same
row from inside two different processess results in blocking second process
to the end of transaction in the first one.
In real OLTP application second process can't wait too long. After few
seconds server should return with
message 'lock timeout exceeded'. I modify postgres lock manager source code
to obtain that functionality.
I take advantage of deadlock detection mechanism. Currently deadlock
detection routine initialy check for
simple deadlock detection between two processess, next insert lock into lock
queue and after
DEADLOCK_CHECK_TIMER seconds run HandleDeadLock to comprehensive deadlock
detection.
To obtain 'timeout on lock' feature I do as follow:
1. Add new configure parameter. I add #define statement in file
include/config.in
#define NO_WAIT_FOR_LOCK 1
In the future somebody can add new option to SQL SET command
2. Modify HandleDeadLock routine. In file backend/storage/lmgr/proc.c change
lines 866-870
if (!DeadLockCheck(MyProc, MyProc-waitLock))
{
UnlockLockTable();
return;
}
to
if (!NO_WAIT_FOR_LOCK)
{
if (!DeadLockCheck(MyProc, MyProc-waitLock))
{
UnlockLockTable();
return;
}
}
With this modyfication every conflicting lock wait DEADLOCK_CHECK_TIMER
seconds in queue and returns with error
'deadlock detect'.
Who can add 'timeout on lock' feature to the next postgres server release?
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[HACKERS] RE: [pgAdmin-hackers] PL/pgSQL IDE project
-Original Message- From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]] Sent: 07 April 2001 15:24 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [pgAdmin-hackers] PL/pgSQL IDE project Hello all, I would like to inform you all that I am currently working on the implementation of PL/pgSQL packages on both server-side (PostgreSQL 7.1) and client-side (PgAdmin). The idea is to add an PL/pgSQL Integrated Development Environment to pgadmin. Help and suggestions needed. If someone is already working on a similar project, let me know how I can help. For discussion, please register on mailto:[EMAIL PROTECTED] mailing list. Help and suggestions needed ! Hi Jean-Michel, Sounds great. My only concern is that you consider the way different code has already been implemented in pgAdmin eg: 1) Any server side objects (SSOs) such as tables, functions or views should be prefixed 'pgadmin_'. There is a mechanism in place in basSQL.bas which will autorepair/upgrade SSOs. In the case of upgrades there is an SSO version number stored in basGlobal.bas. If this doesn't match the version number in the pgadmin_param table then an upgrade will occur. 2) Use the same error handling that is already implemented elsewhere. Where applicable, be sure to reuse existing code like the SQL Wizard - no point in writing another one! Good luck, Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] --tuning compile and runtime option (?)
I like this. Ensure that tips can be dumped into a log file -- preferably separate from the main one -- so it can be run on a live system for a short period of time, recorded then analyzed later. -- Rod Taylor There are always four sides to every story: your side, their side, the truth, and what really happened. - Original Message - From: "Bruce Momjian" [EMAIL PROTECTED] To: "Justin Clift" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, April 09, 2001 12:18 AM Subject: Re: [HACKERS] "--tuning" compile and runtime option (?) My idea was to have PostgreSQL output tips to help performance. The TODO item is: * Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER I also will be writing an article on performance tuning this month. What parameters would these options you suggest control? I usually prefer options that have more concrete effect. Just thinking about the future directions PostgreSQL is taking, and it seems (just a feeling) like most people prefer it to be as self tuning as possible. In trying to think about how it will/would do that I think PostgreSQL will need to know "how much" of the resources of the server its on, it's allowed to take. Can think of three scenario's, 1) Single-purpose PostgreSQL server 2) shared function server (i.e. Apache, Postgres, etc on the same box) 3) Embedded or otherwise resource limited server (Palmtop, etc). When we get around to PostgreSQL's self-tuning ability being actively developed (and I think Bruce has done some of the very start with his monitor program), perhaps having a compile time option to set the default for the server, and a runtime option in case it changes? i.e. --tuning=superserver --tuning=shared --tuning=embedded postmaster -t superserver postmaster -t shared postmaster -t embedded What do people think? Regards and best wishes, Justin Clift P.S. - I'm not on the Hackers mailing list from this account. Can anyone responding please include me directly in their replies? -- "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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- 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 6: Have you searched our list archives? http://www.postgresql.org/search.mpl ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] timeout on lock feature
Hi,
I implement additional server functionality. Currently (v7.0.3), executing
SQL update statement on the same
row from inside two different processess results in blocking second process
to the end of transaction in
the first one. In real OLTP application second process can't wait too long.
After few seconds server should
return to the application message:'lock timeout exceeded'. I modify postgres
lock manager source code to
obtain that functionality. I take advantage of deadlock detection mechanism.
Currently deadlock
detection routine initialy check for simple deadlock detection between two
processess, next insert lock
into lock queue and after DEADLOCK_CHECK_TIMER seconds run HandleDeadLock to
comprehensive deadlock detection.
To obtain 'timeout on lock' feature I do as follow:
1. Add new configure parameter. Currently I add #define statement in file
include/config.in
#define NO_WAIT_FOR_LOCK 1
In the future somebody can add new option to SQL SET command
2. Modify HandleDeadLock routine. In file backend/storage/lmgr/proc.c change
lines 866-870
if (!DeadLockCheck(MyProc, MyProc-waitLock))
{
UnlockLockTable();
return;
}
to
if (!NO_WAIT_FOR_LOCK)
{
if (!DeadLockCheck(MyProc, MyProc-waitLock))
{
UnlockLockTable();
return;
}
}
With this modyfication every conflicting lock wait DEADLOCK_CHECK_TIMER
seconds in queue and returns with error
'deadlock detect'.
Who can add this simply 'timeout on lock' implementation to the next
postgres server release?
---(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] --tuning compile and runtime option (?)
Hi Bruce, My thought on this is more for an "overall effect". Down The Track (i.e. in a few versions or so) I'm thinking, rightly or wrongly, that PostgreSQL will become Very Good at tuning itself. It would be a good thing if PostgreSQL could know just how fair it can play in regards to the server it's working on. For example, if lets say it's installed on a server in which it's the only important thing. i.e. OS + PostgreSQL and thats about it. Indicating to the PostgreSQL server that's it's allowed to consume all the available resources to its maximum benefit would allow possible future "self-tuning" algorithms to say "well, in these circumstances the best way to deal with the present load is X". And it would do things without regard for other possible services, as it would know that it's running by itself. This would be something like a "--tuning=superserver" compile-time option or run-time flag. Conversely, the PostgreSQL server may be on a box with several other services, like Apache, MySQL, FTP daemons, and so forth. In that case it would possibly select different algorithms, knowing that it had to "play fair" with the server's resources. This may be indicated to it by a "--tuning=shared" compile-time option or run-time flag. And similar for embedded systems, where there is a lower or different resource allocation strategy. This is a general indication of thoughts I was having last night and this morning, and I bring it up more as a point of interest and wondering if others see that it may be of benefit. Presently we have to benchmark and then hand-tune the servers ourselves, and thats good. I'm thinking more about PostgreSQL's internal ways of dealing with queries and handling of resources though, in a second-by-second situation. What do you think? Regards and best wishes, Justin Clift Bruce Momjian wrote: My idea was to have PostgreSQL output tips to help performance. The TODO item is: * Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER I also will be writing an article on performance tuning this month. What parameters would these options you suggest control? I usually prefer options that have more concrete effect. Just thinking about the future directions PostgreSQL is taking, and it seems (just a feeling) like most people prefer it to be as self tuning as possible. In trying to think about how it will/would do that I think PostgreSQL will need to know "how much" of the resources of the server its on, it's allowed to take. Can think of three scenario's, 1) Single-purpose PostgreSQL server 2) shared function server (i.e. Apache, Postgres, etc on the same box) 3) Embedded or otherwise resource limited server (Palmtop, etc). When we get around to PostgreSQL's self-tuning ability being actively developed (and I think Bruce has done some of the very start with his monitor program), perhaps having a compile time option to set the default for the server, and a runtime option in case it changes? i.e. --tuning=superserver --tuning=shared --tuning=embedded postmaster -t superserver postmaster -t shared postmaster -t embedded What do people think? Regards and best wishes, Justin Clift P.S. - I'm not on the Hackers mailing list from this account. Can anyone responding please include me directly in their replies? -- "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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- 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 -- "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 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] timeout on lock feature
If you can't handle the SET variable stuff, we can do it over here.
Thanks.
Hi,
I implement additional server functionality. Currently (v7.0.3), executing
SQL update statement on the same
row from inside two different processess results in blocking second process
to the end of transaction in
the first one. In real OLTP application second process can't wait too long.
After few seconds server should
return to the application message:'lock timeout exceeded'. I modify postgres
lock manager source code to
obtain that functionality. I take advantage of deadlock detection mechanism.
Currently deadlock
detection routine initialy check for simple deadlock detection between two
processess, next insert lock
into lock queue and after DEADLOCK_CHECK_TIMER seconds run HandleDeadLock to
comprehensive deadlock detection.
To obtain 'timeout on lock' feature I do as follow:
1. Add new configure parameter. Currently I add #define statement in file
include/config.in
#define NO_WAIT_FOR_LOCK 1
In the future somebody can add new option to SQL SET command
2. Modify HandleDeadLock routine. In file backend/storage/lmgr/proc.c change
lines 866-870
if (!DeadLockCheck(MyProc, MyProc-waitLock))
{
UnlockLockTable();
return;
}
to
if (!NO_WAIT_FOR_LOCK)
{
if (!DeadLockCheck(MyProc, MyProc-waitLock))
{
UnlockLockTable();
return;
}
}
With this modyfication every conflicting lock wait DEADLOCK_CHECK_TIMER
seconds in queue and returns with error
'deadlock detect'.
Who can add this simply 'timeout on lock' implementation to the next
postgres server release?
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
--
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 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] MySQL vs. Postgres - congratulations to the postgres team
DISCLAIMER: don't take this as MySQL flaming (it isn't) or personally, this are just my observations on an application, not a benchmark. Today I tried a quite simple, mostly write database (HTTP logging). * Postgres peaked at 709 inserts/sec (committed after 3 seconds or 100 inserts, whichever comes first) * MySQL peaked at 735 inserts/sec (no transactions) However, MySQL completly choked over when trying to query something usefull out of the database while the inserts are running (at full speed). Postgres worked like a charm. The only real advantage of mysql was a simple "select count(1) from logs", which mysql answered immidiatly,while postgres did a full table scan. For querying the DB, postgres won, my queries ran about 12% faster in Postgres than MySQL. Given the fact that the "one-user" case was MySQL's real advantage up to now, Postgres 7.1 will be an important milestone. -- === Mario Weilguni KPNQwest Austria GmbH Senior Engineer Web Solutions Nikolaiplatz 4 tel: +43-316-8138248020 graz, austria fax: +43-316-813824-26 http://www.kpnqwest.at e-mail: [EMAIL PROTECTED] === ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] timeout on lock feature
I can imagine some people wanting this. However, 7.1 has new deadlock
detection code, so I would you make a 7.1 version and send it over. We
can get it into 7.2. I think we need a SET variable, and it should
default to OFF.
Good idea. Thanks.
Hi,
I implement additional server functionality. Currently (v7.0.3), executing
SQL update statement on the same
row from inside two different processess results in blocking second process
to the end of transaction in
the first one. In real OLTP application second process can't wait too long.
After few seconds server should
return to the application message:'lock timeout exceeded'. I modify postgres
lock manager source code to
obtain that functionality. I take advantage of deadlock detection mechanism.
Currently deadlock
detection routine initialy check for simple deadlock detection between two
processess, next insert lock
into lock queue and after DEADLOCK_CHECK_TIMER seconds run HandleDeadLock to
comprehensive deadlock detection.
To obtain 'timeout on lock' feature I do as follow:
1. Add new configure parameter. Currently I add #define statement in file
include/config.in
#define NO_WAIT_FOR_LOCK 1
In the future somebody can add new option to SQL SET command
2. Modify HandleDeadLock routine. In file backend/storage/lmgr/proc.c change
lines 866-870
if (!DeadLockCheck(MyProc, MyProc-waitLock))
{
UnlockLockTable();
return;
}
to
if (!NO_WAIT_FOR_LOCK)
{
if (!DeadLockCheck(MyProc, MyProc-waitLock))
{
UnlockLockTable();
return;
}
}
With this modyfication every conflicting lock wait DEADLOCK_CHECK_TIMER
seconds in queue and returns with error
'deadlock detect'.
Who can add this simply 'timeout on lock' implementation to the next
postgres server release?
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
--
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 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] Configure problems on Solaris 2.7, pgsql 7.02 and 7.03
Mathijs Brands wrote: SNIP If you want to start running your production machine in august, it would be a very good idea to start using 7.1 now, since the stable release will most likely be out before then (probably april or early may). You seem to be using the Cygnus version of GCC. I'm not sure that will work ok, although it most likely does. The version of make and sed you're using are ok, so they shouldn't be causing your problems. Since it took me a couple of days to respond, it's possible that you've already resolved this problem. Have you? If not, you might try a binary distribution of pgsql instead. Or you could mail me the errors you're receiving. Maybe I can figure it out. No promises though. Thanks, and thanks to all who responded. I experimented with a couple of configs and finally went back to 7.0.3 and edited the configure script so that it didn't pass 'cc --version' to sed (cheers to Tom Lane for pointing out the multiple-line output). This worked and compiled, but postmaster gave me a nasty memory error which the FAQ was able to provide a workaround for - shmget failed (invalid argument) was the error. Seems my kernel isn't properly configured for postGres (along with all the other things that are wrong with my system). I'm currently passing -N 16 -B 32 to the postmaster and it is running - haven't tested it yet tho'. Are there optimum parameters for these numbers, before I get around to getting my sysadmins to fix my kernel for me? The testing should really be finished by next week and there's no way they'll get it right before then. Also how much difference will this make? I'm noticing slower queries but better scaleability to bigger tables than MySQL at the minute, although my tests were far from optimised, and I have only just come back to this. I could probably have got 7.1RC2 working as well, I was just hoping the above error was specific to that version and not to my system :-). When we set up the proper test environment (which won't be for a few weeks), we'll probably use that (assuming no-one here decides to spend 50 grand on Oracle, or MySQL doesn't suddenly pip the post in the tests :-). Thanks again. Ciaran. -- Ciaran Johnston Ericsson Systems Expertise Ltd., Athlone Co. Westmeath Eire email: [EMAIL PROTECTED] Phone: +353 902 31274 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] --tuning compile and runtime option (?)
Hi Bruce, My thought on this is more for an "overall effect". Down The Track (i.e. in a few versions or so) I'm thinking, rightly or wrongly, that PostgreSQL will become Very Good at tuning itself. It would be a good thing if PostgreSQL could know just how fair it can play in regards to the server it's working on. OK, what options would you recommend be auto-tuned in each circumstance? I can imagine open files and maybe sortmemory, but even then, other backends can affect the proper value. Share memory usually has a kernel limit which prevents us from auto-tuning that too much. -- 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 4: Don't 'kill -9' the postmaster
[HACKERS] Truncation of char, varchar types
Excessively long values are currently silently truncated when they are inserted into char or varchar fields. This makes the entire notion of specifying a length limit for these types kind of useless, IMO. Needless to say, it's also not in compliance with SQL. How do people feel about changing this to raise an error in this situation? Does anybody rely on silent truncation? Should this be user-settable, or can those people resort to using triggers? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Truncation of char, varchar types
On Mon, Apr 09, 2001 at 09:20:42PM +0200, Peter Eisentraut wrote: Excessively long values are currently silently truncated when they are inserted into char or varchar fields. This makes the entire notion of specifying a length limit for these types kind of useless, IMO. Needless to say, it's also not in compliance with SQL. How do people feel about changing this to raise an error in this situation? Does anybody rely on silent truncation? Should this be user-settable, or can those people resort to using triggers? Yes, detecting and reporting errors early is a Good Thing. You don't do anybody any favors by pretending to save data, but really throwing it away. We have noticed here also that object (e.g. table) names get truncated in some places and not others. If you create a table with a long name, PG truncates the name and creates a table with the shorter name; but if you refer to the table by the same long name, PG reports an error. (Very long names may show up in machine- generated schemas.) Would patches for this, e.g. to refuse to create a table with an impossible name, be welcome? Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Truncation of char, varchar types
After v7.1 is released ... ?
On Mon, 9 Apr 2001, Peter Eisentraut wrote:
Excessively long values are currently silently truncated when they are
inserted into char or varchar fields. This makes the entire notion of
specifying a length limit for these types kind of useless, IMO. Needless
to say, it's also not in compliance with SQL.
How do people feel about changing this to raise an error in this
situation? Does anybody rely on silent truncation? Should this be
user-settable, or can those people resort to using triggers?
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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
[HACKERS] libpq PQexec call of COPY
Hi,
My generic problem is performance when copying very large amounts of data to a db from
multiple clients.
I am writing a C program on Linux Redhat6.2 that accesses a 7.0.3 database using
libpq. I
would like to be able to do a printf through STDOUT (or another file pointer) TO the
database via a
PQexec call of COPY. Something like this would be ideal:
PQexec(conn, "COPY moncoverage from STDOUT");
I have been unable to figure out if this is possible. I understand that I can do this
via stdin,
but I don't want the user to make the entry, I want the executable to do it and still
enjoy the
performance of the COPY command.
I also understand that I can open a pipe to psql and do it through there like this:
FILE *ofp = popen("psql -a -c 'COPY tablename from stdin' -d dbname -h host","w");
for(i=0;i15000;i++)
fprintf(ofp,"%s\n",row[i]);
fprintf(ofp,"\\.\n");
pclose(ofp);
However, performance is extremely important to me in this application. I already have
a connection
open to the db in the C executable to do 10 inserts, so it I would like to go ahead
and use that
connection to perform my PQexec(conn,'COPY...') to reduce connection overhead. Also,
I am assuming that
the PQexec call makes a more efficient connection that the popen to psql and COPY
scheme. During trial
runs my server maintains 34 postmaster processes -- there has to be a better way to do
this.
Any help would be greatly appreciated. Please let me know if this is the wrong place
to post this.
---(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
At 1:50 AM -0400 4/6/01, Tom Lane wrote: "Henry B. Hotz" [EMAIL PROTECTED] writes: Bottom line: 7.1RC1 passes most of the regression tests on NetBSD/macppc. The only thing that surprised me here was all of the warnings from libreadline calls: tab-complete.c: In function `initialize_readline': tab-complete.c:103: warning: assignment from incompatible pointer type tab-complete.c: In function `psql_completion': tab-complete.c:292: warning: passing arg 2 of `completion_matches' from incompatible pointer type tab-complete.c:296: warning: passing arg 2 of `completion_matches' from incompatible pointer type What version of libreadline do you have installed, and how does it declare completion_matches()? I have whatever is standard on NetBSD 1.5. I noticed that configure found a readline.h include file, but NetBSD doesn't integrate the current GNU implementation. I did not do a test of psql to see if the feature worked. I'm sure you could "fix" this problem if you installed GNU readline and referenced it in the build. Since Solaris had even worse issues with needing GNU support utilities installed this didn't seem like a big deal to me. OTOH it could confuse a new user. Signature held pending an ISO 9000 compliant signature design and approval process. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: --tuning compile and runtime option (?)
An excellent idea. I suspect you'll get a biased resonse from the -hackers folks. This really is an excellent idea. Those options cover I think the main scenarios, with the first two options being the most important. Ideally you'd basically sample server specs (speed, # of procs, mem etc) and set up for that based on profile. It should then be possible to dump the settings that are used (--tuning = these cmdline --options changed from defaults). Novices can use it to get of the ground, intermediate level dba's can use it as a sizing tool, and -hackers can flame each other over its very existence. August - Original Message - From: "Justin Clift" [EMAIL PROTECTED] Newsgroups: comp.databases.postgresql.hackers Sent: Sunday, April 08, 2001 11:36 PM Subject: "--tuning" compile and runtime option (?) Hi guys, Just thinking about the future directions PostgreSQL is taking, and it seems (just a feeling) like most people prefer it to be as self tuning as possible. In trying to think about how it will/would do that I think PostgreSQL will need to know "how much" of the resources of the server its on, it's allowed to take. Can think of three scenario's, 1) Single-purpose PostgreSQL server 2) shared function server (i.e. Apache, Postgres, etc on the same box) 3) Embedded or otherwise resource limited server (Palmtop, etc). When we get around to PostgreSQL's self-tuning ability being actively developed (and I think Bruce has done some of the very start with his monitor program), perhaps having a compile time option to set the default for the server, and a runtime option in case it changes? i.e. --tuning=superserver --tuning=shared --tuning=embedded postmaster -t superserver postmaster -t shared postmaster -t embedded What do people think? Regards and best wishes, Justin Clift ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: [GENERAL] JDBC and Perl compiling problems w/ postgresql-7.1rc4
Charlie Derr wrote:
This sounds like the problem with the version of gcc
that is included with rh7.0
If you don't want to upgrade gcc to a newer version,
I think you can fix the problem by "mv"ing gcc to brokengcc
and then creating creating a new symlink gcc to kgcc. Redhat
included a non-broken gcc in the distro and called it kgcc.
I did what you suggested and nothing changed.
Actually, JDBC problem seems to be ant related
as it did not exist w/ version 7.0.3.
The perl problem is definitely coming from libperl.a
file as specifically mentioned in the Makefile.
Suggestions??
Regards,
HY
~ -Original Message-
~ From: [EMAIL PROTECTED]
~ [mailto:[EMAIL PROTECTED]]On Behalf Of Homayoun
~ Yousefi'zadeh
~ Sent: Monday, April 09, 2001 6:33 PM
~ To: [EMAIL PROTECTED]
~ Subject: [GENERAL] JDBC and Perl compiling problems w/ postgresql-7.1rc4
~
~
~ Hello there,
~
~ I first ran configure with the following options
~
~ ./configure --with-perl --with-tcl --enable-odbc --with-java
~ --enable-syslog --enable-debug
~
~ and then compiled postgresql-7.1rc4 on Redhat 7.0 successfully
~ with the exceptions in JDBC and Perl modules as
~ indicated below.
~
~ -
~
~ gmake[3]: Entering directory
~ `/usr/pgsql-pkg/postgresql-7.1rc4/src/interfaces/jdbc'
~ /usr/jakarta/jakarta-ant/bin/ant -buildfile ../../../build.xml -Dmajor=7
~ -Dminor=1 -Dfullversion=7.1rc4 -Ddef_pgport=5432
~ Buildfile: ../../../build.xml
~
~ jar:
~
~ call:
~
~ prepare:
~
~ check_versions:
~
~ driver:
~ Configured build for the JDBC2 edition driver.
~
~ compile:
~ [javac] Compiling 41 source files to
~ /usr/pgsql-pkg/postgresql-7.1rc4/src/interfaces/jdbc/build
~ [javac] Modern compiler is not available - using classic compiler
~
~ BUILD FAILED
~
~ /usr/pgsql-pkg/postgresql-7.1rc4/src/interfaces/jdbc/build.xml:99:
~ Cannot use classic compiler, as it is not available
~
~ Total time: 0 seconds
~
~ -
~
~!-- This is the core of the driver. It is common for all three
~ versions --
~
~ target name="compile" depends="prepare,check_versions,driver"
~
~ !-- The following is line 99 of build.xml *** --
~ javac srcdir="${src}" destdir="${dest}"
~
~include name="${package}/**" /
~exclude name="${package}/core/ConnectionHook.java"
~ unless="jdk1.3+" /
~exclude name="${package}/jdbc1/**" if="jdk1.2+" /
~exclude name="${package}/jdbc2/**" unless="jdk1.2+" /
~exclude name="${package}/largeobject/PGblob.java"
~ unless="jdk1.2+" /
~exclude name="${package}/largeobject/PGclob.java"
~ unless="jdk1.2+" /
~exclude name="${package}/PostgresqlDataSource.java"
~ unless="jdk1.2e+" /
~exclude name="${package}/xa/**" unless="jdk1.2e+" /
~exclude name="${package}/test/**" unless="junit" /
~ /javac
~ copy todir="${dest}" overwrite="true" filtering="on"
~fileset dir="${src}"
~ include name="**/*.properties" /
~ exclude name="${dest}/**" /
~/fileset
~ /copy
~/target
~
~
~ I have both j2se version 1.3 and ant installed on the machine.
~
~
~ gmake[4]: Entering directory
~ `/usr/pgsql-pkg/postgresql-7.1rc4/src/pl/plperl'
~ *
~ * Cannot build PL/Perl because libperl is not a shared library.
~ * Skipped.
~ *
~
~ It seems like that the compiler does not like the fact that
~
~ /usr/lib/perl5/5.6.0/i386-linux/CORE/libperl.a
~
~ is not a shared object.
~ -
~
~ Your comments to resolve these issues is greatly
~ appreciated.
~
~ BTW, rserv module in contrib directory now compiles
~ beautifully.
~
~ Regards,
~ HY
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] JDBC and Perl compiling problems w/ postgresql-7.1rc4
Charlie Derr wrote:
This sounds like the problem with the version of gcc that is included with
rh7.0
If you don't want to upgrade gcc to a newer version, I think you can fix the
problem by "mv"ing gcc to brokengcc and then creating creating a new symlink
gcc to kgcc. Redhat included a non-broken gcc in the distro and called it
kgcc.
I did what you suggested and nothing changed.
Actually, JDBC problem seems to be ant related
as it did not exist w/ version 7.0.3.
The perl problem is definitely coming from libperl.a
file as specifically mentioned in the Makefile.
Suggestions??
Regards,
HY
~ -Original Message-
~ From: [EMAIL PROTECTED]
~ [mailto:[EMAIL PROTECTED]]On Behalf Of Homayoun
~ Yousefi'zadeh
~ Sent: Monday, April 09, 2001 6:33 PM
~ To: [EMAIL PROTECTED]
~ Subject: [GENERAL] JDBC and Perl compiling problems w/ postgresql-7.1rc4
~
~
~ Hello there,
~
~ I first ran configure with the following options
~
~ ./configure --with-perl --with-tcl --enable-odbc --with-java
~ --enable-syslog --enable-debug
~
~ and then compiled postgresql-7.1rc4 on Redhat 7.0 successfully
~ with the exceptions in JDBC and Perl modules as
~ indicated below.
~
~ -
~
~ gmake[3]: Entering directory
~ `/usr/pgsql-pkg/postgresql-7.1rc4/src/interfaces/jdbc'
~ /usr/jakarta/jakarta-ant/bin/ant -buildfile ../../../build.xml -Dmajor=7
~ -Dminor=1 -Dfullversion=7.1rc4 -Ddef_pgport=5432
~ Buildfile: ../../../build.xml
~
~ jar:
~
~ call:
~
~ prepare:
~
~ check_versions:
~
~ driver:
~ Configured build for the JDBC2 edition driver.
~
~ compile:
~ [javac] Compiling 41 source files to
~ /usr/pgsql-pkg/postgresql-7.1rc4/src/interfaces/jdbc/build
~ [javac] Modern compiler is not available - using classic compiler
~
~ BUILD FAILED
~
~ /usr/pgsql-pkg/postgresql-7.1rc4/src/interfaces/jdbc/build.xml:99:
~ Cannot use classic compiler, as it is not available
~
~ Total time: 0 seconds
~
~ -
~
~!-- This is the core of the driver. It is common for all three
~ versions --
~
~ target name="compile" depends="prepare,check_versions,driver"
~
~ !-- The following is line 99 of build.xml *** --
~ javac srcdir="${src}" destdir="${dest}"
~
~include name="${package}/**" /
~exclude name="${package}/core/ConnectionHook.java"
~ unless="jdk1.3+" /
~exclude name="${package}/jdbc1/**" if="jdk1.2+" /
~exclude name="${package}/jdbc2/**" unless="jdk1.2+" /
~exclude name="${package}/largeobject/PGblob.java"
~ unless="jdk1.2+" /
~exclude name="${package}/largeobject/PGclob.java"
~ unless="jdk1.2+" /
~exclude name="${package}/PostgresqlDataSource.java"
~ unless="jdk1.2e+" /
~exclude name="${package}/xa/**" unless="jdk1.2e+" /
~exclude name="${package}/test/**" unless="junit" /
~ /javac
~ copy todir="${dest}" overwrite="true" filtering="on"
~fileset dir="${src}"
~ include name="**/*.properties" /
~ exclude name="${dest}/**" /
~/fileset
~ /copy
~/target
~
~
~ I have both j2se version 1.3 and ant installed on the machine.
~
~
~ gmake[4]: Entering directory
~ `/usr/pgsql-pkg/postgresql-7.1rc4/src/pl/plperl'
~ *
~ * Cannot build PL/Perl because libperl is not a shared library.
~ * Skipped.
~ *
~
~ It seems like that the compiler does not like the fact that
~
~ /usr/lib/perl5/5.6.0/i386-linux/CORE/libperl.a
~
~ is not a shared object.
~ -
~
~ Your comments to resolve these issues is greatly
~ appreciated.
~
~ BTW, rserv module in contrib directory now compiles
~ beautifully.
~
~ Regards,
~ HY
~
~
~ ---(end of broadcast)---
~ TIP 4: Don't 'kill -9' the postmaster
~
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: --tuning compile and runtime option (?)
I'd be happy to see during initial setup a few questions go by that would size the underlying OS properly as well. We all do the same things with a new system, increase filesystem limits etc... Some of these options (on a dedicated postgresql) are gimme's. Why not do them once upfront, prompt the user (share memory, file handles) are to low, should I increase the limits? I'd love it, and some of the "PostgreSQL doesn't scale even the the load is low" complaints would go away. The hitch I can see is that much will be distribution/platform specific, but those don't change that radically that motivated volunteers couldn't keep pace. August "Bruce Momjian" [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... OK, what options would you recommend be auto-tuned in each circumstance? I can imagine open files and maybe sortmemory, but even then, other backends can affect the proper value. Share memory usually has a kernel limit which prevents us from auto-tuning that too much. -- 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 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: [GENERAL] JDBC and Perl compiling problems w/ postgresql-7.1rc4
"Homayoun Yousefi'zadeh" [EMAIL PROTECTED] writes: I did what you suggested and nothing changed. Actually, JDBC problem seems to be ant related as it did not exist w/ version 7.0.3. You might want to double-check that JAVAHOME (sp?) is set before you make. I had problems building with Ant until I figured that out. If you look in the Ant docs it tells you how to set that variable (I think). The perl problem is definitely coming from libperl.a file as specifically mentioned in the Makefile. No solution for this except to get the Perl sources, configure it to build a shared libperl.so, and build and install the whole thing. None of the RPM packages that I know of supply a shared library for Perl. -Doug ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[GENERAL] Re: [HACKERS] JDBC and Perl compiling problems w/ postgresql-7.1rc4
Doug McNaught wrote: I did what you suggested and nothing changed. Actually, JDBC problem seems to be ant related as it did not exist w/ version 7.0.3. You might want to double-check that JAVAHOME (sp?) is set before you make. I had problems building with Ant until I figured that out. If you look in the Ant docs it tells you how to set that variable (I think). Thanks for the response. I actually went thru the full exercise when I was compiling Tomcat engine with Ant. Every thing seems to be set up properly. This is a part od /etc/profile file that shows the settings of environmental variables. PATH="$PATH:/usr/X11R6/bin:/usr/jbuilder4/bin:/usr/jdk1.3/bin:/usr/jakarta/jakarta-ant/bin:/usr/j2e e1.3/bin:/usr/local/pgsql/bin" MANPATH=$MANPATH:/usr/local/pgsql/man export JAVA_HOME=/usr/jdk1.3 export JAVAHOME=/usr/jdk1.3 export J2EE_HOME=/usr/j2ee1.3 export ANT_HOME=/usr/jakarta/jakarta-ant export JAKARTA_HOME=/usr/jakarta export TOMCAT_HOME=/usr/jakarta/dist/tomcat export LD_LIBRARY_PATH=/usr/local/pgsql/lib export PGDATA=/usr/local/pgsql/data Did you use j2se 1.3_02 for Linux from Sun to build the driver? BTW, I did not have any problem building the driver under version 7.0.3. The perl problem is definitely coming from libperl.a file as specifically mentioned in the Makefile. No solution for this except to get the Perl sources, configure it to build a shared libperl.so, and build and install the whole thing. None of the RPM packages that I know of supply a shared library for Perl. This is what I was not hoping for. Why does version 7.0.3 not have the problem? Do you guys suggest I go thru the exercise of building libperl.so or this is going to be fixed w/ the official release? Best, HY ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: [GENERAL] JDBC and Perl compiling problems w/postgresql-7.1rc4
Yes, and also rerun ./configure --with-java ... after you set JAVA_HOME in your shell environment. Norm -- Norman Clarke Combimatrix Corp Software Development Harbour Pointe Tech Center 6500 Harbour Heights Pkwy, Suite 301 Mukilteo, WA 98275 tel: 425.493.2240 fax: 425.493.2010 -- On 9 Apr 2001, Doug McNaught wrote: You might want to double-check that JAVAHOME (sp?) is set before you make. I had problems building with Ant until I figured that out. If you look in the Ant docs it tells you how to set that variable (I think). ---(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] JDBC and Perl compiling problems w/ postgresql-7.1rc4
"Homayoun Yousefi'zadeh" [EMAIL PROTECTED] writes: Thanks for the response. I actually went thru the full exercise when I was compiling Tomcat engine with Ant. Every thing seems to be set up properly. This is a part od /etc/profile file that shows the settings of environmental variables. Hmm, nothing obviously wrong there that I can see... Did you use j2se 1.3_02 for Linux from Sun to build the driver? Actually, I think it was Blackdown 1.2.2, with PG7.1beta5 (I haven't tried compiling anything later). If I run into the prblem you're having with RC4 or the release 7.1 (as I plan to compile them soon) I'll try to look into it. BTW, I did not have any problem building the driver under version 7.0.3. I don't think 7.0.x used Ant, so it's not surprising. The perl problem is definitely coming from libperl.a file as specifically mentioned in the Makefile. No solution for this except to get the Perl sources, configure it to build a shared libperl.so, and build and install the whole thing. None of the RPM packages that I know of supply a shared library for Perl. This is what I was not hoping for. Why does version 7.0.3 not have the problem? Because it doesn't have Perl as an embedded procedural language (see below). Do you guys suggest I go thru the exercise of building libperl.so or this is going to be fixed w/ the official release? What you may not be aware of is that there are two places where Perl is used in the build. One is the Perl client library (the 'Pg' module). This should not require libperl.so as all it does is build a bog-standard extension module. The other usage is for Perl as an embedded procedural language like PL/PGSQL. In order to compile this you need a shared libperl. It is not a "bug" in Postgres; it's simply what's required to embed the Perl interpreter into the backend. If you just want the client lib, I think you can ignore the missing libperl.so and the client will be built just fine. PL/Perl isn't that useful right now anyhow since it doesn't have an interface to the backend's query mechanism. -Doug ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
