Re: [ADMIN] [PERFORM] Postgres log(pg_logs) have lots of message

2013-04-12 Thread Jeff Janes
On Wednesday, April 10, 2013, Nik Tek wrote: Hi Bambi, Thank you the prompt reply. This table is very volatile, lot of inserts/updates happen on this tables(atleast 20~30 inserts/min). That number of inserts per minute is not all that many. I suspect that you have sessions which are

Re: [ADMIN] with PostgreSQL 9.1.9,the stats collector process is not work!

2013-04-12 Thread X.H.----WANG
OK! Thank you so much for your reply! The Streaming Replication is used. Due to a need,We need to switch the roles of master and slave. So I shut down the Master at first,Then promoted the Salve to The new Master(pg_ctl promote -D). Every thing is ok but the stats infos is null on the new

Re: [ADMIN] regexp_replace grief

2013-04-12 Thread Albe Laurenz
Armin Resch wrote: Not sure this is the right list to vent about this but here you go: I) select regexp_replace('BEFORE.AFTER','(.*)\..*','\1','g') Substring II) select regexp_replace('BEFORE.AFTER','(.*)\\..*','\\1','g') Substring Executing (II) against pg 8.4.4 or 9.0.4 yields 'BEFORE',

Re: [ADMIN] after 9.2.4 patch vacuumdb -avz not analyzing all tables

2013-04-12 Thread Mike Broers
On further review this particular server skipped from 9.2.2 to 9.2.4. This is my most busy and downtime sensitive server and I was waiting on a maintenance window to patch to 9.2.3 when 9.2.4 dropped and bumped up the urgency. However, I have 3 other less busy production servers that were all

Re: [ADMIN] after 9.2.4 patch vacuumdb -avz not analyzing all tables

2013-04-12 Thread Scott Marlowe
Does this behavior only affect the 9.2 branch? Or was it ported to 9.1 or 9.0 or 8.4 as well? On Thu, Apr 11, 2013 at 7:48 PM, Kevin Grittner kgri...@ymail.com wrote: Tom Lane t...@sss.pgh.pa.us wrote: However I've got to say that both of those side-effects of exclusive-lock abandonment

Re: [ADMIN] after 9.2.4 patch vacuumdb -avz not analyzing all tables

2013-04-12 Thread Kevin Grittner
Scott Marlowe scott.marl...@gmail.com wrote: Does this behavior only affect the 9.2 branch? Or was it ported to 9.1 or 9.0 or 8.4 as well? After leaving it on master for a while to see if anyone reported problems in development, I back-patched as far as 9.0 in time for the 9.2.3 (and related)

Re: [ADMIN] with PostgreSQL 9.1.9,the stats collector process is not work!

2013-04-12 Thread Prashanth Ranjalkar
Thanks for the details. pgstat.stat file get created on the start of the server or automatically created when not found under pg_stat_tmp however it's not the case and not possible to restart the server. I assume there are no privileges problem on the new master server for this file creation.

Re: [ADMIN] after 9.2.4 patch vacuumdb -avz not analyzing all tables

2013-04-12 Thread Mike Broers
Looks like psql vacuum (verbose, analyze) is not reflecting in pg_stat_user_tables as well in some cases. In this scenario I run the command, it outputs all the deleted pages etc (unlike the vacuumdb -avz analyze that seemed to be skipped in the log), but it does not update pg_stat_user_tables.

Re: [ADMIN] regexp_replace grief

2013-04-12 Thread Armin Resch
Thx, Albe. I tested both proposals, and I gravitate now more towards the E'' nomenclature since it avoids something like this: $pg_bs_char = ( $dbh-{pg_server_version} = 90100 ) ? \\ : ; Hoping for a long half life of the E'' nomenclature ... -ar On Fri, Apr 12, 2013 at 5:16 AM, Albe

Re: [ADMIN] regexp_replace grief

2013-04-12 Thread Alvaro Herrera
Armin Resch escribió: Thx, Albe. I tested both proposals, and I gravitate now more towards the E'' nomenclature since it avoids something like this: $pg_bs_char = ( $dbh-{pg_server_version} = 90100 ) ? \\ : ; Hoping for a long half life of the E'' nomenclature ... E'' is very unlikely

[ADMIN] ?????? [ADMIN] with PostgreSQL 9.1.9,the stats collector process is not work!

2013-04-12 Thread X.H.----WANG
I reindexed the system catalogs in all databases on the Master,then tried to vacuum one table ,the warning message existed again(pgstat wait timeout). I had a little frustrated but after I killed the stats collector process (kill -9), every thing is ok when the stats collector process occurs

[ADMIN] LOG: could not truncate directory pg_subtrans: apparent wraparound

2013-04-12 Thread Jorge Torralba
I have seen various email about this but no resolution. Is this something to be concerned about? Is there a action plan that needs to be taken to resolve this? I am running 8.3.23 on centos Thanks for looking! Jorge Torralba Note: This communication may contain

[ADMIN] Recommended Swap space

2013-04-12 Thread Nik Tek
Hi, What is the recommended swap space for postgres or 9.0.11 or 9.2.3 on linux(3.0.58-0.6) RAM on the hox is 32GB. Thank you Nik

Re: [ADMIN] [PERFORM] Recommended Swap space

2013-04-12 Thread Scott Marlowe
My experience is that you're best off either with a swap space that matches or exceeds physical memory, or none at all. The linux kernel swap daemon (kswapd) gets confused and behaves badly with small swap spaces, especially the more memory you have. Good news is that hard drives are cheap and 32G

Re: [ADMIN] [PERFORM] Recommended Swap space

2013-04-12 Thread Claudio Freire
On Fri, Apr 12, 2013 at 6:15 PM, Scott Marlowe scott.marl...@gmail.com wrote: The really messed up bit is that the problems with the kswapd won't show up for weeks, months, or sometimes even longer. The symptoms of a kswapd problem is that swap is mostly full, but there's LOTS of free memory /

Re: [ADMIN] [PERFORM] Recommended Swap space

2013-04-12 Thread Scott Marlowe
No, I've had it happen with NUMA turned off. The NUMA issues are with zone_reclaim_mode. If you have it set to 1 (default on a lot of big machines) it can cause serious problems with performance as well. On Fri, Apr 12, 2013 at 3:21 PM, Claudio Freire klaussfre...@gmail.comwrote: On Fri, Apr