Обсуждение: My pg_xlog directory is becoming huge !?

Hi all,

We tried to replicate our database and since this moment, our pg_xlog
directory is becoming HUGE ! (more than 500 Gb !)

In fact, each minute, there is a new file of 16Mb, called like
00000001000001370000004D ...

This is our main parameters in postgresql.conf



The replication is stopped (it was only a test). And I cannot put
wal_level=minimal without having an error at startup.

Do you have any idea to reduce the size of the directory ?

Thank you a lot.



--
View this message in context: http://postgresql.nabble.com/My-pg-xlog-directory-is-becoming-huge-tp5920762.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.

> Hi all,
>
> We tried to replicate our database and since this moment, our pg_xlog
> directory is becoming HUGE ! (more than 500 Gb !)
>
> In fact, each minute, there is a new file of 16Mb, called like
> 00000001000001370000004D ...
>
> This is our main parameters in postgresql.conf
>
>
>
> The replication is stopped (it was only a test). And I cannot put
> wal_level=minimal without having an error at startup.
>
> Do you have any idea to reduce the size of the directory ?


What schema type of replication you use?




--
Saludos,
Gilberto Castillo
ETECSA, La Habana, Cuba

ben.play wrote:
> We tried to replicate our database and since this moment, our pg_xlog
> directory is becoming HUGE ! (more than 500 Gb !)
> 
> In fact, each minute, there is a new file of 16Mb, called like
> 00000001000001370000004D ...
> 
> This is our main parameters in postgresql.conf
> 
> 
> 
> The replication is stopped (it was only a test). And I cannot put
> wal_level=minimal without having an error at startup.
> 
> Do you have any idea to reduce the size of the directory ?

First you got to find out what is causing this.

Do you use streaming replication with replication slots?
Then this can happen if a standby is down and has stopped receiving WAL.

Find out with

   SELECT slot_name, slot_type, active, xmin, catalog_xmin, restart_lsn FROM pg_replication_slots;

If there is a slot that is not active, that may be your problem.

Compare "restart_lsn" with the current LSN:

   SELECT pg_current_xlog_location();

and "xmin" with the current transaction ID:

   SELECT txid_current();


If that is your problem, restart the standby and let it catch up.
If that is not possible, delete the replication slot with

   SELECT pg_drop_replication_slot('slotname');


Other than that, large "pg_xlog" can be caused by a high value of "checkpoint_segments"
(before version 9.5) or "max_wal_size" (from 9.5 on) on the primary.

Of course, a high value for "wal_keep_segments" on the primary can also be the cause.

Yours,
Laurenz Albe