From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SetBufferCommitInfoNeedsSave and race conditions |
Date: | 2007-09-26 08:33:51 |
Message-ID: | 200709260833.l8Q8Xqs10993@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)2ndquadrant(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-09-26 08:34:27 | Re: Postgresql.conf cleanup |
Previous Message | Bruce Momjian | 2007-09-26 08:31:38 | Re: Bgwriter LRU cleaning: we've been going at this all wrong |