On Thu, 2007-06-28 at 20:23 -0400, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > On Thu, 2007-06-28 at 15:16 -0400, Tom Lane wrote:
> >> A quick grep suggests that VACUUM FULL might be at risk here.
>
> > No we're clear: I caught that issue specifically for VACUUM FULL fairly
> > early on. VF assumes all hint bits are set after the first scan, so we
> > flush prior to the scan to ensure its safe to set the hint bits.
>
> Flush what prior to the scan?
>
> The methodology I suggested earlier (involving tracking LSN only at the
> level of pg_clog pages) isn't going to make that work, unless you
> somehow force the XID counter forward to the next page boundary.
> It might be that that level of tracking is too coarse anyway, since
> it essentially says that you can't hint any transaction until the
> next 32K-transaction boundary is reached.
Solutions I'm going for are these:
- Force XLogFlush() prior to initial VF scan. Tqual will set hint bits
if WAL has been flushed, else it will be deferred, so no WAL flushes
will be forced by normal hint bit setting and VF will work without
needing any crufty special cases or rework of VF logic.
- Use Tom's LSN tracking at clog page level. Make the LSN tracking store
an array of LSNs rather than just one. Array size is fixed at
NUMBER_TRACKED_LSNS_PER_PAGE, so that each LSN covers
32,000/NUMBER_TRACKED_LSNS_PER_PAGE transactions. I'd guess that storing
8 per page would be optimal, so each stored xid would track 4,000
transactions - probably around 1 sec worth of transactions when the
feature is used.
Comments?
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
