Re: Too many WAL file created

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: 'Gabriel Fernández Martínez *EXTERN*' <gfernandez(at)hotelbeds(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Too many WAL file created
Date: 2017-03-15 09:44:09
Message-ID: A737B7A37273E048B164557ADEF4A58B53A0A9DD@ntex2010i.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Gabriel Fernández Martínez wrote:
> Thank you for your suggestions has been so usefull. Regarding your tips:
> 1º Backup: You are right, we are using meanwhile a pg_dump to have a backup till the issue could be
> solved.
> 2º Logging: You are right, I include the current setup, not the log conf in use to gather the stats, I
> used the suggested parameter (log_statement = all) and I only capture SELECT statements
> 3º I agree, a Select cannot increase the size of the WAL file.
>
> Regarding your suggestions:
> 1) Change "log_statement" to "all" and activate the changes with "pg_ctl reload": already done an no
> update captured.
> 2) There might be a long running statement that gets logged only once: already done, no long running
> transaction
> 3) Autovacuum, I have not tested before, I have enabled log_autovacuum_min_duration = 0, no background
> process has been identified.

Then you have conclusively proved that WAL is not growing for this database cluster.

The only remaining options are:
- You are looking at the wrong PostgreSQL database cluster.
- You missed the statements in the log.
Note that other statements than UPDATE also create WAL, like INSERT, DELETE and COPY.
Also note that SQL is case insensitive.

Yours,
Laurenz Albe

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Samed YILDIRIM 2017-03-15 11:21:22 Re: Postgres - Replication
Previous Message jasoninmel 2017-03-15 04:59:42 Postgres - Replication