On Thu, Dec 20, 2012 at 1:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavan Deolasee <pavan.deolasee@gmail.com> writes:
>> On Thu, Dec 20, 2012 at 10:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Seems unlikely to be a win. We only care about freezing tuples in the
>>> context of being able to advance a relation-wide relfrozenxid horizon.
>>> Freezing pages retail accomplishes nothing whatsoever towards that goal,
>>> unless you have some way to know that no new freeze work will be needed
>>> on the page before the next vacuum freeze happens. Otherwise, you're
>>> just moving portions of the work from background vacuuming into
>>> foreground processes, with no benefit gained thereby.
>
>> If we can establish an invariant that a all-visible page is always
>> fully freezed, then vacuum freeze does not need to look at those pages
>> again.
>
> We're not going to do that, because it would require freezing tuples
> immediately after they fall below the RecentGlobalXmin horizon. This
> would be a significant loss of capability from a forensic standpoint,
> not to mention breaking existing applications that look at xmin to
> determine whether a tuple has recently been updated. Besides which,
> I think it would result in a large increase in the WAL volume emitted
> by prune operations (hint bit setting doesn't require WAL, unlike
> freezing). I don't believe for a minute your argument that it would
> result in a net reduction in WAL.
I don't think the above makes sense, because making a page all-visible
already requires emitting a WAL record. Pavan didn't say "freeze the
page every time we set a hint bit"; he said "freeze the page every
time it gets marked all-visible". And that's already WAL-logged.
Now, there is a downside: right now, we play a tricky little game
where we emit a WAL record for setting the visibility map bit, but we
don't actually set the LSN of the heap page. It's OK because it's
harmless if the PD_ALL_VISIBLE bit makes it to disk and the
visibility-map doesn't, and also because the PD_ALL_VISIBLE bit can be
set without relying on the previous page contents. But doing anything
more complicated with the same WAL record, like freezing, is likely to
require setting the LSN on the heap page. And that will result in a
huge increase in WAL traffic when vacuuming an insert-only table.
Whee, crash recovery is fun.
With respect to the forensic problem, we've previously discussed
setting a HEAP_XMIN_FROZEN bit in the tuple header rather than
overwriting the xmin with FrozenXID.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company