Skip site navigation (1) Skip section navigation (2)

Re: archived WALL files question

From: Frederiko Costa <frederiko(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: archived WALL files question
Date: 2010-04-19 17:49:51
Message-ID: (view raw or whole thread)
Lists: pgsql-admin

On 04/19/2010 10:26 AM, Kevin Grittner wrote:
> Frederiko Costa<frederiko(at)gmail(dot)com>  wrote:
>> I have seen new 16 MB segments files created in pg_xlog directory
>> as time goes on. Honestly, I did not understand why it got
>> created, because I was running it on a VM and there was no
>> activity. I got several new segments.
>> If I run the command you asked, this is the output. Neither
>> segment is copied, nor a new segment file gets created:
>>    select pg_switch_xlog();
>>    pg_switch_xlog
>> ----------------
>>    0/81000088
>> (1 row)
> What version of PostgreSQL is this?
> What do you see if you run?:
> show archive_command;
cp -p %p /mnt/data/%f
> show archive_mode;
> show archive_timeout;
I have just enabled that. Now, log files are being copied directly to 
the /mnt/data dir. However, the same segments are not in the pg_xlog 
dir. Is this a default behaviour?

Must I set archive_timeout? I don't think I want that, because, 
specially for the next few months, where the activity would be very 
limited and I would get several zero written segments just because 
timeout has been reached. Is this approach recommended anyway? Or is it 
better to use this approach even having limited approach?

> Check your log file from the time you ran pg_switch_xlog to look for
> any messages which might give a clue to what's happening.
The log files did not write anything about pg_switch_xlog.
> -Kevin

In response to


pgsql-admin by date

Next:From: Kevin GrittnerDate: 2010-04-19 18:41:43
Subject: Re: archived WALL files question
Previous:From: Kevin GrittnerDate: 2010-04-19 17:26:19
Subject: Re: archived WALL files question

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group