Re: Trimming transaction logs after extended WAL archive failures
От | Steven Schlansker |
---|---|
Тема | Re: Trimming transaction logs after extended WAL archive failures |
Дата | |
Msg-id | 509E80A0-D8D8-4173-8279-1B0ABA943820@likeness.com обсуждение исходный текст |
Ответ на | Re: Trimming transaction logs after extended WAL archive failures (Adrian Klaver <adrian.klaver@aklaver.com>) |
Ответы |
Re: Trimming transaction logs after extended WAL archive
failures
|
Список | pgsql-general |
On Mar 25, 2014, at 3:52 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > On 03/25/2014 01:56 PM, Steven Schlansker wrote: >> Hi everyone, >> >> I have a Postgres 9.3.3 database machine. Due to some intelligent work on the part of someone who shall remain nameless,the WAL archive command included a ‘> /dev/null 2>&1’ which masked archive failures until the disk entirely filledwith 400GB of pg_xlog entries. >> >> I have fixed the archive command and can see WAL segments being shipped off of the server, however the xlog remains ata stable size and is not shrinking. In fact, it’s still growing at a (much slower) rate. > > So what is wal_keep_segments set at in postgresql.conf? > 5000. There are currently about 18000 WAL segments in pg_xlog. >> >> I’ve seen references to people just deleting “old” segment files or using pg_resetxlog to fix this situation, howeverI already know that the response from the mailing list will be “that’s insane, don’t do that”. >> >> So what is the correct solution to pursue here? The steady state of the machine should have enough space, I just needto reclaim some of it... Thanks for any guidance! >> >> Steven >> >> >> > > > -- > Adrian Klaver > adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: