Re: pg_xlog is getting bigger

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>
Cc: AI Rumman <rummandba(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_xlog is getting bigger
Date: 2012-12-20 00:55:18
Message-ID: 26417.1355964918@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> writes:
> On 12/19/2012 04:12 PM, Tom Lane wrote:
>> Idle transactions shouldn't have anything to do with pg_xlog bloat.
>> What causes xlog bloat is inability to release old WAL because either
>> (a) we're not able to complete checkpoints, or (b) WAL archiving is
>> enabled but malfunctioning, and the old WAL segments are being kept
>> pending successful archiving.

> Its obvious I am missing something important about WAL.
> Scenario:
> 1) Transaction is opened and say many UPDATEs are done.
> 2) This means there is now an old tuple and a new tuple for the previous
> row.
> 3) The transaction is not committed.

> I assumed the WAL logs contained information necessary to either go
> forward to the new on commit or go back to the old on rollback.

No, you're thinking about an Oracle-style WAL implementation. We don't
do rollback; both tuple versions are kept around until VACUUM decides it
can reclaim one or the other. WAL only need be kept back to the latest
checkpoint, even if there are open transactions that are much older.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2012-12-20 01:06:37 Re: pg_xlog is getting bigger
Previous Message AI Rumman 2012-12-20 00:54:56 Re: pg_xlog is getting bigger