Re: [GENERAL] SSL Compression - doesn't work?
You mentioned you are using the Windows version; unless something has
changed recently in their build process, the included openssl library is
not linked against zlib and therefore compression is not possible unless
you recompile the Windows version yourself.
*Terence J. Ferraro*
On Thu, May 8, 2014 at 9:36 AM, Adrian Klaver adrian.kla...@aklaver.comwrote:
On 05/08/2014 01:22 AM, Krystian Bigaj wrote:
Hi,
I'm wondering how, and if SSL compression works correctly.
Here is how I tested it:
- PostgreSQL 9.3.4 x86 on Windows 7 x64
- .crt/.key files by openssl, and placed in database cluster folder
- postgres.exe ran with: --ssl=on --ssl_cert_file=test.crt
--ssl_key_file=test.key
- connection made by pgadmin with SSL=prefer, SSL Compression=True
- when connected I see in properties: Encryptions=SSL encrypted, SSL
Compression=yes
- I've dumped TCP transfer and I can tell that data is encrypted
Now when I run query like:
SELECT lpad('', 1024*1024, 'A')
then I see that there is a TCP transfer of 1,01MB (so 1MB of string
data, and some pg header/data).
If I turn off SSL Compression data transfer between postgres and pgadmin
is still 1,01MB (but in properties I see SSL Compression=no)
It looks like SSL compression doesn't work, or am I missing something?
http://www.postgresql.org/docs/9.3/static/libpq-connect.html
sslcompression
If set to 1 (default), data sent over SSL connections will be
compressed (this requires OpenSSL version 0.9.8 or later). If set to 0,
compression will be disabled (this requires OpenSSL 1.0.0 or later). This
parameter is ignored if a connection without SSL is made, or if the version
of OpenSSL used does not support it.
So what version of OpenSSL are you using?
Best regards,
Krystian Bigaj
--
Adrian Klaver
adrian.kla...@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Timezone information
Or, if you don't mind a little patching: http://pastebin.com/5AyaX2RF That restores the pre-9.1 functionality of determining the timezone on postmaster start. As has been pointed out, their new stuff is more useful if you're shipping instances to the farthest reaches of the planet (We've only got clients in North America at the moment). You will undoubtedly need to make some modifications to patch with 9.3, but I've got hundreds of 9.2 instances in the field now that, well, just work. *Terence J. Ferraro* On Wed, Feb 19, 2014 at 5:10 PM, Andrew Sullivan a...@crankycanuck.cawrote: On Thu, Feb 20, 2014 at 03:37:20AM +0530, Dev Kumkar wrote: But better is to set the TimeZone. Now haven't done anything special but JDBC is working with setting TimeZone and ODBC not. So what should I look from here now? I think your client should set the TimeZone at connection time. That's going to yield the most predictable behaviour for the users, I suspect. A -- Andrew Sullivan a...@crankycanuck.ca -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] configuring timezone
See the archived thread here: http://www.postgresql.org/message-id/CAEghcWD8DXjroBYCZsdGrx+cHTCbCbW9es2uQ+o7a8NZ61JT=q...@mail.gmail.com Short version: Sorry, but you're going to need to recompile if you want that behavior. Here's a diff applied against 9.2.1 http://pastebin.com/5AyaX2RF. I've deployed the patched version a couple dozen times now and it is working flawlessly. T.J. On Wed, Feb 6, 2013 at 1:32 PM, Igor Neyman iney...@perceptron.com wrote: Timezone configuration parameter (defaulting to system timezone) worked fine for us before upgrading from 8.4. to 9.2. ** ** Now we’ve got a problem. 9.2 Release Notes says: · Identify the server time zone during initdb, and set postgresql.confentries timezonehttp://www.postgresql.org/docs/9.2/static/runtime-config-client.html#GUC-TIMEZONEand log_timezonehttp://www.postgresql.org/docs/9.2/static/runtime-config-logging.html#GUC-LOG-TIMEZONEaccordingly (Tom Lane) This avoids expensive time zone probes during server start. ** ** Question: is there any way to revert back to old behavior so that server will probe system’s timezone on startup (default to OS timezone on startup) instead setting it during initdb? Obviously, without recompiling/rebuilding Postgres. ** ** I’m dealing with the situation, where system is being built in one timezone (could be anywhere around the globe), and then moved to other (not known during system build) location with different timezone. After relocation, OS timezone will change, but we can’t allow user to edit timezone parameter in Postgresql.conf. ** ** Regards, Igor Neyman
Re: [GENERAL] configuring timezone
Sorry, but from what I understand the change is permanent. If recompile is not an option but you're on Windows let me know; I do have binaries available.. On Wed, Feb 6, 2013 at 2:05 PM, Igor Neyman iney...@perceptron.com wrote: Terence, ** ** Thanks for quick reply, I read your thread (Dec, 2012) before posting my question. But, recompile is not an option for me. Was hoping, that something regarding this issue changed since… ** ** Igor Neyman ** ** *From:* Terence Ferraro [mailto:terencejferr...@gmail.com] *Sent:* Wednesday, February 06, 2013 1:45 PM *To:* Igor Neyman *Cc:* pgsql-general@postgresql.org *Subject:* Re: [GENERAL] configuring timezone ** ** See the archived thread here: http://www.postgresql.org/message-id/CAEghcWD8DXjroBYCZsdGrx+cHTCbCbW9es2uQ+o7a8NZ61JT=q...@mail.gmail.com Short version: Sorry, but you're going to need to recompile if you want that behavior. Here's a diff applied against 9.2.1 http://pastebin.com/5AyaX2RF. I've deployed the patched version a couple dozen times now and it is working flawlessly. T.J. On Wed, Feb 6, 2013 at 1:32 PM, Igor Neyman iney...@perceptron.com wrote: Timezone configuration parameter (defaulting to system timezone) worked fine for us before upgrading from 8.4. to 9.2. Now we’ve got a problem. 9.2 Release Notes says: · Identify the server time zone during initdb, and set postgresql.confentries timezonehttp://www.postgresql.org/docs/9.2/static/runtime-config-client.html#GUC-TIMEZONEand log_timezonehttp://www.postgresql.org/docs/9.2/static/runtime-config-logging.html#GUC-LOG-TIMEZONEaccordingly (Tom Lane) This avoids expensive time zone probes during server start. Question: is there any way to revert back to old behavior so that server will probe system’s timezone on startup (default to OS timezone on startup) instead setting it during initdb? Obviously, without recompiling/rebuilding Postgres. I’m dealing with the situation, where system is being built in one timezone (could be anywhere around the globe), and then moved to other (not known during system build) location with different timezone. After relocation, OS timezone will change, but we can’t allow user to edit timezone parameter in Postgresql.conf. Regards, Igor Neyman ** **
Re: [GENERAL] configuring timezone
9.2.1 was the version standard when I was building and deploying...so no, I probably will not (personally) be updating anytime soon... However, if you're interested, I'll see if I can find a place tonight or tomorrow to put these binaries (they are 32-bit as well), source, etc (sourceforge maybe?). I can also include to inno setup script that builds an installer similar to the EnterpriseDB version; that is, it automatices the service setup, creates a postgres user, etc. Hell, I may as well include the pre-built installer, too, if you don't want to customize anything.. In addition to the timezone fix, I (originally) wanted to build my own Windows installer because the EnterpriseDB version does NOT link against zlib with respect to openssl. In other words, no compressed ssl connections are possible with the currently distributed windows version. This one is linked against zlib (and the speed increase is quite significant). T.J. On Wed, Feb 6, 2013 at 3:23 PM, Igor Neyman iney...@perceptron.com wrote: I am on Windows (both 32 and 64 bit) using 32-bit Postgres. So, your binaries are for 9.2.1, you aren’t planning to go to 9.2.2? ** ** ** ** *From:* Terence Ferraro [mailto:terencejferr...@gmail.com] *Sent:* Wednesday, February 06, 2013 3:07 PM *To:* Igor Neyman *Cc:* pgsql-general@postgresql.org *Subject:* Re: [GENERAL] configuring timezone ** ** Sorry, but from what I understand the change is permanent. If recompile is not an option but you're on Windows let me know; I do have binaries available.. On Wed, Feb 6, 2013 at 2:05 PM, Igor Neyman iney...@perceptron.com wrote: Terence, Thanks for quick reply, I read your thread (Dec, 2012) before posting my question. But, recompile is not an option for me. Was hoping, that something regarding this issue changed since… Igor Neyman *From:* Terence Ferraro [mailto:terencejferr...@gmail.com] *Sent:* Wednesday, February 06, 2013 1:45 PM *To:* Igor Neyman *Cc:* pgsql-general@postgresql.org *Subject:* Re: [GENERAL] configuring timezone See the archived thread here: http://www.postgresql.org/message-id/CAEghcWD8DXjroBYCZsdGrx+cHTCbCbW9es2uQ+o7a8NZ61JT=q...@mail.gmail.com Short version: Sorry, but you're going to need to recompile if you want that behavior. Here's a diff applied against 9.2.1 http://pastebin.com/5AyaX2RF. I've deployed the patched version a couple dozen times now and it is working flawlessly. T.J. On Wed, Feb 6, 2013 at 1:32 PM, Igor Neyman iney...@perceptron.com wrote: Timezone configuration parameter (defaulting to system timezone) worked fine for us before upgrading from 8.4. to 9.2. Now we’ve got a problem. 9.2 Release Notes says: · Identify the server time zone during initdb, and set postgresql.confentries timezonehttp://www.postgresql.org/docs/9.2/static/runtime-config-client.html#GUC-TIMEZONEand log_timezonehttp://www.postgresql.org/docs/9.2/static/runtime-config-logging.html#GUC-LOG-TIMEZONEaccordingly (Tom Lane) This avoids expensive time zone probes during server start. Question: is there any way to revert back to old behavior so that server will probe system’s timezone on startup (default to OS timezone on startup) instead setting it during initdb? Obviously, without recompiling/rebuilding Postgres. I’m dealing with the situation, where system is being built in one timezone (could be anywhere around the globe), and then moved to other (not known during system build) location with different timezone. After relocation, OS timezone will change, but we can’t allow user to edit timezone parameter in Postgresql.conf. Regards, Igor Neyman ** **
Re: [GENERAL] Default timezone changes in 9.1
On Sun, Dec 16, 2012 at 1:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: Andres Freund and...@2ndquadrant.com writes: On 2012-12-16 12:25:13 -0500, Tom Lane wrote: I'm still not sure what the OP actually wants to accomplish by moving the time of making the choice. I guess he wants - and I have seen that before - to use the same postgresql.conf across a number of different systems. Where the individual servers are in different timezones... Doing initdb, extracting the few values that should be kept, and then putting those and an include for the common configuration file into the configuration is harder than just replacing it alltogether. True, but if he's assuming that timezone is and always will be the only thing that needs to vary across servers, he's in for pain someday anyway. Probably sooner not later. Another possibility for per-server overrides is to specify stuff on the postmaster command line, assuming you're using a custom start script that you can tweak to add parameter settings there. regards, tom lane With the exception of a few parameters (max_connections and the ssl related variables that we enable), the default configuration file (circa 9.0) has worked extremely well across 100+ machines so far over the last two years and counting. However, we are simply deploying these on commodity machines ($300-400 off the shelf). Spec wise such machines have not changed significantly (I suppose the shift away from higher clock speeds to more cores can be thanked for that). So, really as a testament to Postgres and all the hard work you guys have done, using the same config file has really been quite pain free (truly, thanks!) =) I'm not at all concerned about mainlining the regression; for windows machines we have to compile postgres ourselves anyways to enable SSL compression (the EnterpriseDB ssl library is not linked against zlib). However, I figured I'd at least gain a little google notoriety with some specific keywords in case anyone else makes the leap from 9.0 forward and also found this runtime functionality useful. I will take your custom script suggestion into consideration. However, since the regression seems to be working well, I think I'm likely to keep the simplicity of the system determining this for me. Thanks, T.J.
[GENERAL] Default timezone changes in 9.1
We recently began upgrading our clients' servers from 9.0 - 9.2. After a few deployments and a little digging we noticed that 9.0 - 9.1 broke the use of no timezone set within postgresql.conf. That is, not setting the option was now defaulting to GMT instead of the system timezone. Unfortunately, this put quite a damper on our one configuration file to rule them all setup across servers located throughout various time zones. I obtained the commit ca4af308c32d03db5fbacb54d6e583ceb904f268 from the git repository and have reversed it against 9.2. Though it didn't apply as smoothly as initially hoped; applying a few of the failed hunks manually allowed me to successfully compile 9.2.1 with these changes reversed. After some (light) testing, the previous functionality of the system choosing the timezone at runtime seems to be functional again. I found this functionality invaluable and figured I'd get the patch ( http://pastebin.com/5AyaX2RF) posted in case anyone else ever needs this functionality back. It works against 9.2.1; no guarantees on future releases of course and YMMV. T.J.
Re: [GENERAL] Default timezone changes in 9.1
Sorry about the double post, I thought the list disallowed attachments so I sent it again with a pastebin link instead of an attachment. This change does not affect the storage at all. If it did, pre-9.1 things would have been a mess. Rather, this allows the system to determine the timezone for localized use at runtime. Post 9.1, the system determines this via initdb data directory initialization and automatically sets it within postgresql.conf. In other words, the default now is *not* GMT but rather the system detected timezone at initdb runtime. Removing that statically set configuration option, in this case, *then* assumes GMT. In other words, it may be 2 AM NZST, but would you really want to walk around and have all of your clocks read 1 PM (GMT)? :) T.J. On Sat, Dec 15, 2012 at 10:35 PM, Gavin Flower gavinflo...@archidevsys.co.nz wrote: On 16/12/12 16:07, Terence Ferraro wrote: We recently began upgrading our clients' servers from 9.0 - 9.2. After a few deployments and a little digging we noticed that 9.0 - 9.1 broke the use of no timezone set within postgresql.conf. That is, not setting the option was now defaulting to GMT instead of the system timezone. Unfortunately, this put quite a damper on our one configuration file to rule them all setup across servers located throughout various time zones. I obtained the commit ca4af308c32d03db5fbacb54d6e583ceb904f268 from the git repository and have reversed it against 9.2. Though it didn't apply as smoothly as initially hoped; applying a few of the failed hunks manually allowed me to successfully compile 9.2.1 with these changes reversed. After some (light) testing, the previous functionality of the system choosing the timezone at runtime seems to be functional again. I found this functionality invaluable and figured I'd get the patch ( http://pastebin.com/5AyaX2RF) posted in case anyone else ever needs this functionality back. It works against 9.2.1; no guarantees on future releases of course and YMMV. T.J. I simply do not understand why you would _NOT_ want to store date/times as GMT! Storing as GMT, allows the times to be easily converted into whatever time zone you are in, also allows for times to be correctly ordered irrespective of time zone. If I make a phone call from Auckland to New York at 2am NZST on Friday, the n my colleague is talking to me at the same time - even though it is still Thursday for them! Cheers, Gavin
Re: [GENERAL] Default timezone changes in 9.1
On Sat, Dec 15, 2012 at 11:54 PM, Gavin Flower gavinflo...@archidevsys.co.nz wrote: Please do not top post, see end of email for rest of reply... (Bottom posting is the convention here, so people can see the context before reading your reply.) On 16/12/12 16:52, Terence Ferraro wrote: Sorry about the double post, I thought the list disallowed attachments so I sent it again with a pastebin link instead of an attachment. This change does not affect the storage at all. If it did, pre-9.1 things would have been a mess. Rather, this allows the system to determine the timezone for localized use at runtime. Post 9.1, the system determines this via initdb data directory initialization and automatically sets it within postgresql.conf. In other words, the default now is *not* GMT but rather the system detected timezone at initdb runtime. Removing that statically set configuration option, in this case, *then* assumes GMT. In other words, it may be 2 AM NZST, but would you really want to walk around and have all of your clocks read 1 PM (GMT)? :) T.J. On Sat, Dec 15, 2012 at 10:35 PM, Gavin Flower gavinflo...@archidevsys.co.nz wrote: On 16/12/12 16:07, Terence Ferraro wrote: We recently began upgrading our clients' servers from 9.0 - 9.2. After a few deployments and a little digging we noticed that 9.0 - 9.1 broke the use of no timezone set within postgresql.conf. That is, not setting the option was now defaulting to GMT instead of the system timezone. Unfortunately, this put quite a damper on our one configuration file to rule them all setup across servers located throughout various time zones. I obtained the commit ca4af308c32d03db5fbacb54d6e583ceb904f268 from the git repository and have reversed it against 9.2. Though it didn't apply as smoothly as initially hoped; applying a few of the failed hunks manually allowed me to successfully compile 9.2.1 with these changes reversed. After some (light) testing, the previous functionality of the system choosing the timezone at runtime seems to be functional again. I found this functionality invaluable and figured I'd get the patch ( http://pastebin.com/5AyaX2RF) posted in case anyone else ever needs this functionality back. It works against 9.2.1; no guarantees on future releases of course and YMMV. T.J. I simply do not understand why you would _NOT_ want to store date/times as GMT! Storing as GMT, allows the times to be easily converted into whatever time zone you are in, also allows for times to be correctly ordered irres pective of time zone. If I make a phone call from Auckland to New York at 2am NZST on Friday, then my colleague is talking to me at the same time - even though it is still Thursday for them! Cheers, Gavin My machine time is stored in GMT, but displayed in local time. If I store time as the local time zone, then I could end up with a file created after I had amended it, or having a negative uptime! Similarly, I want my date/times to be stored in GMT, but displayed in local time. This is similar to storing money as an integer value of cents then formatting it for output with 2 decimal place. Storing money as a double, is a common programming error - though, sometimes storing money as a double is actually valid. The key point is the storage type used should be one most appropriate for processing, and need not be what is displayed. In a database, someone's name will normally be stored in 2 or fields, but printed out as if it had been stored as a single string. Cheers, Gavin All of your points are correct. The patch I provided changes none of that. I think what you're missing here is that the timezone option in postgresql.conf does not change the internals of how a timestamp is stored. Rather, without it, by leaving that option blank, you would NOT see your local time when running SELECT CURRENT_TIMESTAMP. Instead, you'd see the GMT time. Likewise, if I created a configuration file on my local machine, initdb would set the timezone option to US/Eastern and if I then distributed that to other servers located in various timezones they would ALL display CURRENT_TIMESTAMP with reference to US/Eastern instead of the actual machine timezone. Previously (and now, with the patch), leaving the timezone option blank would simply determine, at run time, the machine's time zone and display times in that local timezone. Does that make sense? The timezone parameter has nothing to do with storage types and everything to do with the display of the local time.
Re: [GENERAL] Oracle buys Innobase
Marc G. Fournier wrote: Stupid question, but what does MySQL bring to the equation? Why not just use PostgreSQL in the first place? Simplicity. A huge user base. No one is questioning that pg is a superior product :) http://www.mysql.com/why-mysql/marketshare/ * *with a pinch of salt perhaps ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[GENERAL] Clone a database to other machine
Hi there: I am just wondering if this is a doable method to clone a database to other machine. I have three identical linux serves with postgresql server installed at the same location. I have a new customized database and initial data load into server 1. Can I just copy all of the database filesphysically from server 1 to server 2 and server 3? I assume this is one of the method to restore a database. What I am trying to do is to sell a solution package to clients. The solution will include Linux + Apache+ PHP + PostgreSQL. So every customers will have the same database configuration initially. Any other suggestion? Thanks!
Re: [GENERAL] Can I turn the case sensitive off
This is exactly what I was doing. I use PostgreSQL Manager Pro. The tool covert all my column name and table name in the double quote. So I have all my column/table/function created in upper case (Oracle habit). Now, I have to quote all of them. I should stay with psql, I guess. :-) Thanks! At least I know there are people like out there.. :-) == Then I could not access from psql. After banging my head to the wall for couple days, I then realize I have to use the double quotes. So somehow pgaccess write the create table statements using doble quotes. RDB ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Can I turn the case sensitive off
I am still getting the error. would this matter with 7.3.3 on windows with cygwin? My query only works when I quote the field. Also I have to always use the schema name in the where clause. Is there any way that I can set default schema to app_v08 but not public? Thank you very much! My table users contains a field FIRSTNAME in upper case. app= select FIRSTNAME from api_v08.users; ERROR: Attribute firstname not found app= select firstname from app_v08.users; ERROR: Attribute firstname not found app= select a.firstname from app_v08.users a; ERROR: No such attribute a.firstname app= select a.FIRSTNAME from app_v08.users a; ERROR: No such attribute a.firstname app= select A.FIRSTNAME FROM app_v08.users A; ERROR: Relation A does not exist app= select FIRSTNAME FROM app_v08.users; FIRSTNAME --- Terence (1 row) app= select FIRSTNAME FROM users; ERROR: Relation users does not exist ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[GENERAL] database design of products catalogue
Hi! I would like to create a database for products catalogue. I have many products with different specification. e.g. lamp A: Part no, Color, Raw Material, Wave length, Vf(V)20mA, lv(ucd)10mA ECG:Part no, Type, Iv, KHz, A, W, Im Should I put these products in one table, or in separate? Best regards, Terence ___ Do You Yahoo!? Get your free @yahoo.com.hk address at http://mail.english.yahoo.com.hk ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Where is the physical files of database that I just
IC.. However, my application is critical. So is it possible to backup those 20 user's transactions from log? Oracle and MS SQL can recover to the failure point. Does PostgreSQL support that also? I mean recover from a transaction log and where is the transaction log? Thanks! - Original Message - From: scott.marlowe [EMAIL PROTECTED] To: Terence Chang [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 7:35 AM Subject: Re: [GENERAL] Where is the physical files of database that I just On Wed, 16 Jul 2003, Terence Chang wrote: Great! That is easier than Oracle! Now! I have no excuse not to use PostgreSQL. :-) I got one more question! Is there a way that I can shut down only one database for Cold Backup while other database are running like Oracle does? There's really no need to shut down and do a cold backup. pg_backup backs up databases hot as if they were cold (i.e. it uses a snapshot system). So, if you connect and start pg_dump, and 20 users initiate transactions after that, you see none of those later transactions or any part of them in your backup. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Install new language - Prev: Re: [GENERAL] Are you frustrated with PostgreSQL
Folks: I would like to thank for those who answer my questions. My client have decide to switch from MySQL to PostgreSQL. I have successfully installed PostgreSQL with Cygwin on my XP laptop. It's a good start. I, however, have some other questions. 1. I am viewing the database from both PostgreSQL manager and PgAdmin III. I can see there are three languages (C, Internal, SQL) in PostgreSQL, but not in PgAdmin III. I login with the same user. Any idea? 2. Do I have to install new language pl/pgSQL in order to write functions? 3. When I start PostgreSQL, I found there are at least 4 instance of postgres.exe running as NT services when there is not connection. Each single one use different amount of memory. Is that normal? 4. The stored procedure term confused me. I did not see any create procedure statement in the document. I used a lot of procedures/packages in Oracle and MS-SQL. Are there such things in PostgreSQL? How do I do that in PostgreSQL? Just use Function? I could not find examples on how to call a function like Exec MyFunctionName(..). 5. I start PostgreSQL with the comman pg_ctl start -D /var/pgsql/data I got the following message: It says the database was not shut down properly? What I did wrong? I shut down the database with this command pg_ctl stop -D /var/pgsql/data -m immediate when no connection exist. $ LOG: database system was interrupted at 2003-07-15 23:59:00 USMST LOG: checkpoint record is at 0/8C17D0 LOG: redo record is at 0/8C17D0; undo record is at 0/0; shutdown FALSE LOG: next transaction id: 4428; next oid: 25168 LOG: database system was not properly shut down; automatic recovery in progress LOG: ReadRecord: record with zero length at 0/8C1810 LOG: redo is not required LOG: database system is ready 6. What kind of hardware configuration would you experts recommend for application runnng on one stand along machine. -- Critical but not 24x7 -- RedHat 8, 9? -- PHP 4 -- Apache 2 -- PostgreSQL 7.3.3 -- ODBC -- up to 1500 pages hit and 1000 database hit (select/update/insert) per minute. -- Expect up to 1GB data in the first year -- Expect to spend up to US $2000 for hardware (not include monitor) 7. Is there any experienced PostgreSQL DBA in Phoenix, Arizona USA? Please contact me offline. My client would love to get some help from you on administration/backup/restore stuff as an extra resource. Can you image that I got my PostgreSQL setup and running in few hours. Cool! Thanks! This mailling list is great! You people are great! Terence Chang ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
