Re: pg_xlog size

From: Tech Madhu <technimadhu(at)gmail(dot)com>
To: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: pg_xlog size
Date: 2011-03-16 21:27:17
Message-ID: AANLkTikjuWhaL=dEX8i4o38g0Ej3ZBN_iqF4Wq+ekSWB@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Thank you. I had pg_archivecleanup added in recovery.conf, but on second
look had a typo in the archive dir path. After this change in recovery.conf
and postgres restart, its fine now. Once my archive dir got cleaned up , i
noticed my /var/postgres/data/pg_xlog dir on master also got cleaned up

On Wed, Mar 16, 2011 at 1:27 PM, Euler Taveira de Oliveira <
euler(at)timbira(dot)com> wrote:

> Em 15-03-2011 12:09, Tech Madhu escreveu:
>
> [This is not a performance question, next time post at the appropriate
> list, that is -general]
>
>
> Everything works fine (w.r.t replication), but the pg_xlog size grows
>> continuously, though i had no operations going on. Also the archiving to
>> the other side filled up the other side FS.
>> ls -l /var/postgres/data/pg_xlog | wc -l
>> 103
>>
> Did you consider using pg_archivecleanup [1]?
>
>
> At start, there were only 15 files. The max_wal_segments is 32, but not
>> sure why iam seeing 103 files. Also the archiving dir size doubled
>> (w.r.t number of files archived). and filled up the filesystem.
>> I manually logged into postgres and run checkpoint; did not see any file
>> reduction
>>
>> max_wal_segments [2] is *not* related to archiving activity.
>
>
> [1] http://www.postgresql.org/docs/9.0/static/pgarchivecleanup.html
> [2]
> http://www.postgresql.org/docs/9.0/static/runtime-config-wal.html#GUC-WAL-KEEP-SEGMENTS
>
>
> --
> Euler Taveira de Oliveira
> http://www.timbira.com/
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2011-03-16 21:56:11 Re: Updating histogram_bounds after a delete
Previous Message Kevin Grittner 2011-03-16 19:42:07 Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3