Re: FSM, now without WAL-logging

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FSM, now without WAL-logging
Date: 2008-09-24 07:57:54
Message-ID: 48D9F302.2060902@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> On Mon, 2008-09-22 at 20:43 +0300, Heikki Linnakangas wrote:
>
>> Attached is a revamped version of the FSM rewrite. WAL-logging is now
>> gone. Any inconsistencies between levels of the FSM is fixed during
>> vacuum, and by searchers when they run into a dead end because of a
>> discrepancy. Corruption within FSM pages is likewise fixed by vacuum and
>> searchers.
>>
>> The FSM in a warm standby gets updated by replay of heap CLEAN WAL
>> records. That means that the FSM will reflect the situation after the
>> last vacuum, which is better than what we have now, but not quite
>> up-to-date. I'm worried that this might not be enough...
>
> I hadn't realised you would remove it completely. Did you identify WAL
> as the bottleneck?

No. But it seemed like a sensible thing to do.

> Is there some mid-way point between every time and almost never
> (VACUUM!)?

That's possible. However, if it's not fully WAL-logged, it needs to be
self-correcting, and probably needs to be periodically vacuumed as well.
So you'll get the code complexity of both approaches. I don't think
VACUUM in particular needs to be separately WAL-logged, because we can
easily piggy-back on the HEAP_CLEAN records. The question is whether we
should do the same for every heap insert and update record, or is that
too much overhead?

It looks like truncations do need to be WAL-logged, though.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2008-09-24 09:02:55 Re: [HACKERS] 0x1A in control file on Windows
Previous Message Dimitri Fontaine 2008-09-24 07:50:11 Re: parallel pg_restore