"Tom Lane" <[EMAIL PROTECTED]> writes: > The reason why XLogAsyncCommitFlush() is ugly is that it doesn't > actually accomplish a darn thing, as we now see from this failure: > it does not guarantee that hint bits will get set, because of the > inexact bookkeeping in clog.c. It might marginally improve the > probability that they get set, but that's all. The reason I want > to take it out is mainly that its very existence tempts people to make > the same mistake that was made here.
I don't understand your reasoning here and I would like to understand it so if you don't mind I would like to see if I can work out what you're talking about. Regardless of this point I think the impact of what you were proposing to do to VF instead was much less than Simon seemed to think it was so it seems like a perfectly acceptable solution. As far as I understand the Xlog flush in combination with keeping an exclusive lock on table and always holding locks until the end of the transaction make forcing the hint bits entirely safe. The fragility you see comes from depending on how those three things interact and the difficulty in ensuring that all of those properties are always true. By "marginally improve the probability" you're making a judgement of the probability that programmers will manage to maintain all those properties consistently, not about the probability that the race will occur at run-time? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
