Hi tom lane, Alvaro Herrera Thanks for the good information. It is very helpful. I checked pg_stat_activity and found that I do have a client connection in '<IDLE> in transaction' state. I know this could be caused by not commit a transaction at the end of execution. However, because the PostgreSQL Server has AutoCommit=true as default value, the client connection't transactions should be commited immedidately. It seems the '<IDLE> in transaction' state is not caused by AutoCommit setting. Is there other reasons which could cause a transaction stay in the state and not get finished? As for autovacuum_freeze_max_age setting, I have not changed its default value. The config value in my database server is as below. Which should create a pg_clog file about 50MB at maximum according to http://www.postgresql.org/docs/8.2/interactive/routine-vacuuming.html. #autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum #vacuum_freeze_min_age = 100000000 My pg_clog file sometimes can reach to about 148MB, that is about three times bigger than the expected value. My understanding is that: the pg_clog records transaction commit status data, not the content of the transaction. So a '<IDLE> in transaction' connection should not cause the pg_clog get too big, is that correct? An additional information may be useful here, I have two schemas in a single database. One is a backup schema created from a database backup dump file, another is the public schema (working schema). When restore the database, I used the backup schema to replace the public schema, then the old public schem is deleted, and all client connections are stopped and reconnect to the new public schema. Can this kind of operation could affect pg_clog and pg_subrrans file size? Thanks a lot for your time. Dennis > To: dennis_02_2002(at)hotmail(dot)com> CC: pgsql-interfaces(at)postgresql(dot)org> Subject: Re: [INTERFACES] pg_subtrans directory grows over 1 GB, is there a way to control it? > Date: Fri, 16 May 2008 10:44:31 -0400> From: tgl(at)sss(dot)pgh(dot)pa(dot)us> > Dennis Wang <dennis_02_2002(at)hotmail(dot)com> writes:> > I am using PostgreSQL database in a location recognition application, the files under postgresql/cluster is growing and over a few days it become very large as below. > > /var/opt/postgresql/cluster/data 166015 Kilobytes (the actual database data)> > /var/opt/postgresql/cluster/sys/pg_clog 74188 Kilobytes (transaction commit status data)> > /var/opt/postgresql/cluster/sys/pg_subtrans 1187032 Kilobytes (transaction status data)> > I think the only way pg_subtrans can get that large is if you have a> client that's been sitting holding an open transaction for a very long> time. Take a look in pg_stat_activity.> > The expected size of pg_clog varies depending on what PG version you're> using. In recent releases you can alter autovacuum_freeze_max_age to> trade off the size of pg_clog against the frequency of forced vacuums.> > regards, tom lane > Date: Fri, 16 May 2008 10:39:39 -0400> From: alvherre(at)commandprompt(dot)com> To: dennis_02_2002(at)hotmail(dot)com> CC: pgsql-interfaces(at)postgresql(dot)org> Subject: Re: [INTERFACES] pg_subtrans directory grows over 1 GB, is there a way to control it?> > Dennis Wang wrote:> > > > I am using PostgreSQL database in a location recognition application, the files under postgresql/cluster is growing and over a few days it become very large as below. > > /var/opt/postgresql/cluster/data 166015 Kilobytes (the actual database data)> > /var/opt/postgresql/cluster/sys/pg_clog 74188 Kilobytes (transaction commit status data)> > /var/opt/postgresql/cluster/sys/pg_subtrans 1187032 Kilobytes (transaction status data)> > > > The pg_clog and pg_subtrans can grow when database contains more data and more queries come in. But these figures looks rather large to me because the queries goes in the database are mainly read operation rather than write one. I got a few question to ask here:> > Is there a way to control the size of pg_clog and pg_subtrans? > > Is the file size still be normal for the database of this size (166MB for cluster/data)?> > Does the larger pg_subtrans indicate some bad transaction happens in the database?> > I think it can be an indication that you're leaving transactions running> for too long. Check pg_stat_activity, and if you see '<IDLE> in> transaction', start worrying about that.> > -- > Alvaro Herrera http://www.CommandPrompt.com/> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
_________________________________________________________________
Are you paid what you're worth? Find out: SEEK Salary Centre
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2Fcareer%2Dresources%2Fsalary%2Dcentre%2F%3Ftracking%3Dsk%3Ahet%3Asc%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_salary&_m=EXT