On Thu, Sep 01, 2005 at 09:22:35AM -0400, Tom Lane wrote:
> ITAGAKI Takahiro <itagaki.takahiro@lab.ntt.co.jp> writes:
> > I agree. I think an good position of freezer is on bgwriter.
> > My idea is:
> > 1. Just before bgwriter writes an dirty page in LRU order,
> > 2. Freeze tuples in the page and repair fragmentation.
> > 3. (Replace the fsm page that has least freespace.)
> > 4. Flush the page.
>
> This is a bad idea. The bgwriter isn't the place to be doing freezing,
> because there is no reasonable way for it to guarantee that all old
> tuples in a table (or any larger unit) have been frozen. So you'd still
> need VACUUM to ensure no wraparound. Plus, you can't do such changes
> without emitting an XLOG record, which is something we don't want
> happening in the bgwriter's inner loop. Even more to the point, you
> can't do such changes without getting a superexclusive lock on the page
> (not only locked, but no one else has it pinned), which is a real
> nonstarter for the bgwriter, both for performance and possible deadlock
> issues.
So is this something that another daemon could handle? Presumably one
that would operate on pages before they were written out by bgwriter.
Basically, right now any time someone thinks of something that could be
done in the background, bgwriter is the automatic candidate because it's
the only daemon in the backend. And it's often rejected for valid
technical reasons, but that doesn't mean we can't have additional
daemons that operate either before or after bgwriter.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com 512-569-9461