This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---------------------------------------------------------------------------
Simon Riggs wrote:
> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
