Re: SetBufferCommitInfoNeedsSave and race conditions
От | Bruce Momjian |
---|---|
Тема | Re: SetBufferCommitInfoNeedsSave and race conditions |
Дата | |
Msg-id | 200709260833.l8Q8Xqs10993@momjian.us обсуждение исходный текст |
Ответ на | Re: SetBufferCommitInfoNeedsSave and race conditions ("Simon Riggs" <simon@2ndquadrant.com>) |
Ответы |
Re: SetBufferCommitInfoNeedsSave and race conditions
|
Список | 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@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. +
В списке pgsql-hackers по дате отправления: