From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Remove xmin and cmin from frozen tuples |
Date: | 2005-09-01 13:22:35 |
Message-ID: | 12117.1125580955@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas DAZ SD | 2005-09-01 13:26:25 | Re: Pre-allocated free space for row |
Previous Message | Tom Lane | 2005-09-01 13:15:05 | Re: broken configure, broken makefile? |