Re: [ADMIN] pg_restore on windows with pipe
Ravi, To (attempt to) answer your questions: 1) does the custom archive format of pg_dump needs to be in a file (not pipe) for the pg_restore to seek back &forth ? Not to my knowledge. I suspect that the windows "type" command is adding extra "header" information to the file before passing it to pg_restore, therefore the data blocks are in the wrong position - unless anyone can correct me here? Maybe you could install GnuWin32 (http://gnuwin32.sourceforge.net)? I believe this gives access to the gnu version of "cat" which will allow you to fully emulate Linux. 2) will pg_restore try to do parallel restore of custom archive format dump by default? I believe it'll run serially unless specified to do otherwise. Don't quote me on that though, I may be way off the mark... Cheers ___ This email is intended for the named recipient. The information contained in it is confidential. You should not copy it for any purposes, nor disclose its contents to any other party. If you received this email in error, please notify the sender immediately via email, and delete it from your computer. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company. PCI Compliancy: Please note, we do not send or wish to receive banking, credit or debit card information by email or any other form of communication. Cromwell Tools Limited, PO Box 14, 65 Chartwell Drive Wigston, Leicester LE18 1AT. Tel 0116 2888000 Registered in England and Wales, Reg No 00986161 VAT GB 115 5713 87 900 __
[ADMIN] ls /var/lib/pgsql/data nothing
Hi All; I am root and when I do ls /var/lib/pgsql/data, I do not see anything. Why? I need to find the pg_h.conf file but not able. Any help? Regards Bilal -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] ls /var/lib/pgsql/data nothing
Zitat von bilal ghayyad : Hi All; I am root and when I do ls /var/lib/pgsql/data, I do not see anything. Why? I need to find the pg_h.conf file but not able. "find / -name pg_hba.conf" is your friend... Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: [ADMIN] ls /var/lib/pgsql/data nothing
On Thu, 2011-03-31 at 04:17 -0700, bilal ghayyad wrote: > I am root and when I do ls /var/lib/pgsql/data, I do not see > anything. > > Why? You need to initdb first. I think this is an RPM installation. If so, service postgresql initdb (or service postgresql-9.0 initdb , depending on the version) would work. Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [ADMIN] ls /var/lib/pgsql/data nothing
bilal ghayyad writes: > Hi All; > > I am root and when I do ls /var/lib/pgsql/data, I do not see anything. Try the 'locate' command is it's on your system. If you are able to connect to the DB, show data_directory; Or, sudo su - postgres and see if $PGDATA is set. ps -ef might even show something after the -D option for some sites if DB is running also. > Why? > > I need to find the pg_h.conf file but not able. Do you mean pg_hba.conf? > Any help? > Regards > Bilal -- Jerry Sievers e: gsiever...@comcast.net p: 305.321.1144 -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] ls /var/lib/pgsql/data nothing
Mine is Fedora 10, how it will be? regards bilal --- On Thu, 3/31/11, Devrim GÜNDÜZ wrote: > From: Devrim GÜNDÜZ > Subject: Re: [ADMIN] ls /var/lib/pgsql/data nothing > To: "bilal ghayyad" > Cc: pgsql-admin@postgresql.org > Date: Thursday, March 31, 2011, 7:27 AM > On Thu, 2011-03-31 at 04:17 -0700, > bilal ghayyad wrote: > > I am root and when I do ls /var/lib/pgsql/data, > I do not see > > anything. > > > > Why? > > You need to initdb first. I think this is an RPM > installation. If so, > > service postgresql initdb > (or service postgresql-9.0 initdb , depending on the > version) would > work. > > Regards, > -- > Devrim GÜNDÜZ > Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com > PostgreSQL Danışmanı/Consultant, Red Hat Certified > Engineer > Community: devrim~PostgreSQL.org, > devrim.gunduz~linux.org.tr > http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz > -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] ls /var/lib/pgsql/data nothing
On Thu, 2011-03-31 at 04:37 -0700, bilal ghayyad wrote: > Mine is Fedora 10, how it will be? I already wrote what you need to do. -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
[ADMIN] drive failure
Hello, He had a drive fail in an array and the spare kicked in to replace the failed drive. However, when I query a specific table, I get the below error: ERROR: could not open file "pg_tblspc/16412/PG_9.0_201008051/16419/5875980.7" (target block 2968776487): No such file or directory When I change to this directory, the file in question does not exist. Am I to assume that I'm completely hosed? If the spare kicked in, what happened to the file listed above? Any hints would be most appreciated. Thanks. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] ls /var/lib/pgsql/data nothing
Thanks a lot. And how to make it started automatically when the machine booted? Without need to type the command to start manuall? Regards Bilal --- On Thu, 3/31/11, Devrim GÜNDÜZ wrote: > From: Devrim GÜNDÜZ > Subject: Re: [ADMIN] ls /var/lib/pgsql/data nothing > To: "bilal ghayyad" > Cc: pgsql-admin@postgresql.org > Date: Thursday, March 31, 2011, 7:27 AM > On Thu, 2011-03-31 at 04:17 -0700, > bilal ghayyad wrote: > > I am root and when I do ls /var/lib/pgsql/data, > I do not see > > anything. > > > > Why? > > You need to initdb first. I think this is an RPM > installation. If so, > > service postgresql initdb > (or service postgresql-9.0 initdb , depending on the > version) would > work. > > Regards, > -- > Devrim GÜNDÜZ > Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com > PostgreSQL Danışmanı/Consultant, Red Hat Certified > Engineer > Community: devrim~PostgreSQL.org, > devrim.gunduz~linux.org.tr > http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz > -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] ls /var/lib/pgsql/data nothing
On Thu, 2011-03-31 at 05:52 -0700, bilal ghayyad wrote: > And how to make it started automatically when the machine booted? > Without need to type the command to start manuall? chkconfig postgresql on -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [ADMIN] drive failure
We were able to determine through a few of our queries that an index was corrupt. We did this through the process of elimination however. As a result, I have two questions: How can I determine that we have a corrupt index? How can I determine which datafile (5875980.x) is related to which tablespace? On Thu, 2011-03-31 at 08:38 -0400, Tony Capobianco wrote: > Hello, > He had a drive fail in an array and the spare kicked in to replace the > failed drive. However, when I query a specific table, I get the below > error: > > ERROR: could not open file > "pg_tblspc/16412/PG_9.0_201008051/16419/5875980.7" (target block > 2968776487): No such file or directory > > > When I change to this directory, the file in question does not exist. > Am I to assume that I'm completely hosed? If the spare kicked in, what > happened to the file listed above? Any hints would be most appreciated. > > Thanks. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] drive failure
On Thu, Mar 31, 2011 at 7:11 PM, Tony Capobianco wrote: > We were able to determine through a few of our queries that an index was > corrupt. We did this through the process of elimination however. As a > result, I have two questions: > How can I determine that we have a corrupt index? > Yes, this can be achieved by block level checking with pg_dump utility:: pg_dump -d -p -v >/dev/null If there is any corrupted indexes or tables exists in the Database, it will throw an error with block number. > How can I determine which datafile (5875980.x) is related to which > tablespace? > > Get oid & Name of the tablespace using below command: select oid,* from pg_tablespace; Once you get the oid,tablespace name, you can easily identify the which datafile is related to which tablespace in "pg_tblspc" directory. --Raghu Ram > On Thu, 2011-03-31 at 08:38 -0400, Tony Capobianco wrote: > > Hello, > > He had a drive fail in an array and the spare kicked in to replace the > > failed drive. However, when I query a specific table, I get the below > > error: > > > > ERROR: could not open file > > "pg_tblspc/16412/PG_9.0_201008051/16419/5875980.7" (target block > > 2968776487): No such file or directory > > > > > > When I change to this directory, the file in question does not exist. > > Am I to assume that I'm completely hosed? If the spare kicked in, what > > happened to the file listed above? Any hints would be most appreciated. > > > > Thanks. > > > > -- > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin >
[ADMIN] Freebsd/Postgres/Apache+PHP
Hello Postgres Community, Thank you guys very much for PostgreSQL. To me, its the best database management system under the sun. I am setting up a new jail configuration on FreeBSD with sockets and everything enabled. I can ping localhost fine. The problem is that when I load a script that connects to the database, Postgres says Unable to connect to PostgreSQL server: FATAL: no pg_hba.conf entry for host "x.x.x.x" (my actual web IP). I have done the following on the host machine: I'd like Apache/PHP to just connect to Postgres localhost, not via the jail's IP--thus, no change to pg_hba.conf is needed. If you guys have any suggestions it would be very much appreciated! -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] shared_preload_libraries
Hi all, We are using 9.03 Having shared_preload_libraries = 'auto_explain, pg_stat_statements' set in the conf file causes some one starting up postgres to manually have to hit the enter key. Suprresing this output with pg_ctl would be the best option, but I don't it as an option(silent doesn't cut it). We have a workaround rediriecting stdout to '> /dev/null', but I was hoping for a better solution. What about permanently loading these libraries with ld.so.conf ? ~DjK Starting PostgreSQL: ok postgres@system1:~> < 2011-03-31 15:01:08 EDT> LOG: loaded library "auto_explain" < 2011-03-31 15:01:08 EDT> LOG: loaded library "pg_stat_statements"
Re: [ADMIN] Freebsd/Postgres/Apache+PHP
On 03/31/2011 12:18 PM, babak badaei wrote: Hello Postgres Community, Thank you guys very much for PostgreSQL. To me, its the best database management system under the sun. I am setting up a new jail configuration on FreeBSD with sockets and everything enabled. I can ping localhost fine. The problem is that when I load a script that connects to the database, Postgres says Unable to connect to PostgreSQL server: FATAL: no pg_hba.conf entry for host "x.x.x.x" (my actual web IP). I have done the following on the host machine: I'd like Apache/PHP to just connect to Postgres localhost, not via the jail's IP--thus, no change to pg_hba.conf is needed. If you guys have any suggestions it would be very much appreciated! I have no experience actually using a modern FreeBSD jail, but I do have some questions? 1. Are PHP and PostgreSQL running in different jails? 2. What are the addresses PostgreSQL is set to listen on? 3. What PHP statement are you using to establish the connection? 4. If PHP and PostgreSQL are on different jails, 1. Be sure you are connecting with localhost, not local unix domain sockets (it appears you are based on the error message). 2. Is PHP running on a different jail than PHP? If my reading is correct, a FreeBSD jail is basically a virtual host and has its own IP addresses and I doubt that the loopback localnet is shared among those hosts. 3. What is the IP address of the server and of the client and what PHP connection statement are you using? Cheers, Steve -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] PG 9.0 Replcation
All, I have PG 9.03 setup with master slave native replication. Everything seems to be fine. I have few question or concerns. Coming from MySql background, so trying to setup my expectations for PG. 1. Very Large wal log size. Specially archiving WAL is bigger pain. In our env, the Archive are almost 70GB in 1 day. What is the rule of thumb. How old WAL files one should archive in normal production evn. 2. In mySQL there are some commands to start, stop slave, Show slave status, See the exact position of Slave and Master, view how far slave is behind master. In PG I see only pg_last_xlog_replay_location() and pg_last_xlog_receive_location(). Don't know what those hexadecimal codes means. How can I stop the replication without stopping the slave DB Server etc. 3. Say I stop slave for few hours. How can I find how far behind is slave as compare to master. These are few I have been wondering about, I am sure there will be more soon. If you guys an share you experience, that will be big good resource for many like me. -Jai
[ADMIN] Too many WAL(s) despite low transaction
Dear All, We just migrated our system from Informix/GeneroDB to PostgreSQL 9.03. We are monitoring the situation very closely. Everything seems to be OK except our concern on the build up of WAL files. You see, we cut off from the previous database around 3.30AM. After that we directed our applications to point to PostgreSQL. We already had a Standby machine A up and running as a Secondary for log shipping and replication. We also setup another machine B just to receive the WAL(s) and store it for us to backup later for recovery purposes. As there are no PostgreSQL running in that machine no pg_archive_cleanup is in effect. Our plan is to backup the WAL(s) every 12 hours and then purge them all. But at the rate the logs are building up at machine B, we would possibly ran out of space very soon. But this is the point to note. There is very little transaction taking place and the checkpoint_timeout is set to 35minutes. Despite that the WAL logs are getting shipped every minute. Any clue as to what could be the problem? Thank you. Regards, Selvam
Re: [ADMIN] Too many WAL(s) despite low transaction
* Selva manickaraja (mavle...@gmail.com) wrote: > Any clue as to what could be the problem? Can you provide your postgresql.conf? Little hard to guess at possible mistakes there without it.. Is it exactly once a minute? Stephen signature.asc Description: Digital signature
Re: [ADMIN] Too many WAL(s) despite low transaction
Hi, I'm attaching the file here. As of now it is 874 files within 3 hours. Kindly assist. Thanking in advance. Regards, Selvam On Fri, Apr 1, 2011 at 8:42 AM, Stephen Frost wrote: > * Selva manickaraja (mavle...@gmail.com) wrote: > > Any clue as to what could be the problem? > > Can you provide your postgresql.conf? Little hard to guess at possible > mistakes there without it.. > > Is it exactly once a minute? > >Stephen > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAk2VH4AACgkQrzgMPqB3kihY6ACgkIV9FdfUsT61eKWhzZD0W5SB > vp0AnRXjpsRZ/YZgVcByRppUvldAzBtE > =2gv8 > -END PGP SIGNATURE- > > postgresql.conf Description: Binary data -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Too many WAL(s) despite low transaction
* Selva manickaraja (mavle...@gmail.com) wrote: > I'm attaching the file here. As of now it is 874 files within 3 hours. You have archive_timeout set to '5'. That means "rotate a log file every 5 seconds". You probably want to increase that. Thanks Stephen signature.asc Description: Digital signature
Re: [ADMIN] Too many WAL(s) despite low transaction
If our check_timeout is 30 minutes, what would be an acceptable time limit for archive_timeout? Also since bulk loading/migration of large amount of data was done earlier, do I need to run vacuum etc. I will wait for your reply. Thank you. Regards, Selvam On Fri, Apr 1, 2011 at 9:03 AM, Stephen Frost wrote: > * Selva manickaraja (mavle...@gmail.com) wrote: > > I'm attaching the file here. As of now it is 874 files within 3 hours. > > You have archive_timeout set to '5'. That means "rotate a log file > every 5 seconds". You probably want to increase that. > >Thanks > >Stephen > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAk2VJGgACgkQrzgMPqB3kigM7QCfZ0qTMlLfCpksmAXogWo80ezn > QkQAn1VT2I+y+eMeaoIFEMdeEsnN+uN5 > =lynD > -END PGP SIGNATURE- > >
Re: [ADMIN] Too many WAL(s) despite low transaction
Selva, * Selva manickaraja (mavle...@gmail.com) wrote: > If our check_timeout is 30 minutes, what would be an acceptable time limit > for archive_timeout? They're two different things. Checkpoints are about getting data flushed out to the data files (so they're not just in the WALs), archive_timeout is about how often WAL segments should be forcibly archived (so that the archive server doesn't end up missing data on low-write systems). Typically, I'd pick archive_timeout of around 5m or 10m, depending on how much time you don't mind losing. I'd also compress the WALs (on a low-write system, they're going to have very little data in them). There's also a utility out there, iirc, which will truncate WALs to remove empty space. > Also since bulk loading/migration of large amount of data was done earlier, > do I need to run vacuum etc. Erm, you should be running autovacuum.. Stephen signature.asc Description: Digital signature
Re: [ADMIN] Too many WAL(s) despite low transaction
Since the production database is running, I plan to do now is this 1. Set archive_timeout = 20m (Does the change require db restart to take effect?) 2. Set autovacuum=on and track_count=on (Does the change require db restart to take effect?) Does that mean we are running autovacuum? 3. Run VACUUM FREEZE ANALYZE since bulk loading was done earlier. (Can this be done while the db is active and on production?) All 3 steps is to lower the WAL files that are being shipped out. Is this a workable action to achieve the result required? Please assist. Thank you. Regards, Selvam
Re: [ADMIN] Too many WAL(s) despite low transaction
* Selva manickaraja (mavle...@gmail.com) wrote: > 1. Set archive_timeout = 20m (Does the change require db restart to take > effect?) I *think* it can be changed with just a reload, but I'm not 100% sure. Check your logs after doing the reload, it'll complain if it isn't able to change that parameter on reload. 20m sounds reasonable, still would recommend compressing the WALs if they're likely to be less than full (less than 16M of data in 20m). > 2. Set autovacuum=on and track_count=on (Does the change require db restart > to take effect?) > Does that mean we are running autovacuum? This is the default, so unless you changed the default, yes, it's already running. > 3. Run VACUUM FREEZE ANALYZE since bulk loading was done earlier. (Can this > be done while the db is active and on production?) Yes, you can freeze records while the DB is running (erm, I don't know that you can run it w/o the DB running..). I don't know that I'd jump to running it right away though, unless you know that you need it...? > All 3 steps is to lower the WAL files that are being shipped out. Uhh, the only option that's going to affect that is the first one.. > Is this a workable action to achieve the result required? You probably just need to change archive_timeout and reload the database. Well, you also need to go read the documentation, but that's beside the point. > Please assist. Uhm, pretty sure I have been? Thanks, Stephen signature.asc Description: Digital signature
Re: [ADMIN] Too many WAL(s) despite low transaction
Where you mentioned "after the reload" I suppose you meant restart right? About compressing you mentioned iirc, but how do I use it? are there any examples. I read about pg_compress before. Is that same? The configuration file shows that autovacuum=on and track_count=on to be commented out. That means that it is not running right? If that's the case, just uncommenting it now should get it working right? OK, I'm going to hold on to the VACUUM FREEZE ANALYZE for time being. Yes Stephen you have been extraordinarily helpful. I will wait for your reply. On Fri, Apr 1, 2011 at 10:22 AM, Stephen Frost wrote: > * Selva manickaraja (mavle...@gmail.com) wrote: > > 1. Set archive_timeout = 20m (Does the change require db restart to take > > effect?) > > I *think* it can be changed with just a reload, but I'm not 100% sure. > Check your logs after doing the reload, it'll complain if it isn't able > to change that parameter on reload. > > 20m sounds reasonable, still would recommend compressing the WALs if > they're likely to be less than full (less than 16M of data in 20m). > > > 2. Set autovacuum=on and track_count=on (Does the change require db > restart > > to take effect?) > > Does that mean we are running autovacuum? > > This is the default, so unless you changed the default, yes, it's > already running. > > > 3. Run VACUUM FREEZE ANALYZE since bulk loading was done earlier. (Can > this > > be done while the db is active and on production?) > > Yes, you can freeze records while the DB is running (erm, I don't know > that you can run it w/o the DB running..). I don't know that I'd jump > to running it right away though, unless you know that you need it...? > > > All 3 steps is to lower the WAL files that are being shipped out. > > Uhh, the only option that's going to affect that is the first one.. > > > Is this a workable action to achieve the result required? > > You probably just need to change archive_timeout and reload the > database. Well, you also need to go read the documentation, but that's > beside the point. > > > Please assist. > > Uhm, pretty sure I have been? > >Thanks, > >Stephen > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAk2VNtEACgkQrzgMPqB3kig1ugCeMqz9PWDozSYpfVsJh4SxzitJ > EKAAmQFPiVurdCDNxW5YEKE4JICHHUFq > =mJol > -END PGP SIGNATURE- > >
Re: [ADMIN] Too many WAL(s) despite low transaction
* Selva manickaraja (mavle...@gmail.com) wrote: > Where you mentioned "after the reload" I suppose you meant restart right? I'm not sure offhand if it requires a reload or a restart, that's why I suggested doing a reload than then checking the logs to see if a restart is required. > About compressing you mentioned iirc, but how do I use it? are there any > examples. I read about pg_compress before. Is that same? No, I meant "use gzip". > The configuration file shows that autovacuum=on and track_count=on to be > commented out. That means that it is not running right? If that's the case, > just uncommenting it now should get it working right? Commented out means that the default value is used, which is on for both of those. That means that autovacuum should already be running. Is there some reason you think it isn't? Thanks, Stephen signature.asc Description: Digital signature
Re: [ADMIN] Too many WAL(s) despite low transaction
On Fri, Apr 1, 2011 at 10:35 AM, Stephen Frost wrote: > * Selva manickaraja (mavle...@gmail.com) wrote: > > Where you mentioned "after the reload" I suppose you meant restart right? > > I'm not sure offhand if it requires a reload or a restart, that's why I > suggested doing a reload than then checking the logs to see if a restart > is required. > I have put it in. Log file does not complaint, neither do I see the WAL(s) reducing. So I'm waiting for Friday lunch time in 1 hour to restart the db. > > > About compressing you mentioned iirc, but how do I use it? are there any > > examples. I read about pg_compress before. Is that same? > > > No, I meant "use gzip". > OK, I saw a sample in the PostgreSQL site, I will try that on the development machine first. > > The configuration file shows that autovacuum=on and track_count=on to be > > commented out. That means that it is not running right? If that's the > case, > > just uncommenting it now should get it working right? > > Commented out means that the default value is used, which is on for both > of those. That means that autovacuum should already be running. Is > there some reason you think it isn't? > I see. Cause I was thinking that all these surge of WAL was due to the fact that autovacuum was not running. Is there a utility to check if autovacuum is running or not? Once the db is restarted, I will post the results to you to let you know how well the WAL(s) are fairing. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAk2VOgsACgkQrzgMPqB3kignEgCdFE+Ij+EbX+zC/rUtugZrG1nA > sHoAoIZlmfjTlONs0fPA//Rz6g0HRoVn > =D+LS > -END PGP SIGNATURE- > >
