Quick progress report:
On Thu, 2007-06-21 at 16:05 -0400, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > Completed all of the agreed changes for TG:
All comments changed, plus some refactoring of code.
> Can we fix it to be a read test instead of a write test, that is, if
> we know WAL has been flushed through the target LSN, it's safe to set
> the hint bit, else not?
Still working on this, but I'm getting closer.
I've got the main shape of it now, but I need to look at it with fresh
eyes, so another day on this methinks.
I've got an array of LSNs per clog page, as previously described on
hackers, rather than just one per page as before.
> In general, I think a transaction abort should not need to flush
> anything, since the default assumption is that it crashed anyway.
> Hence for instance recording a transaction abort needn't advance
> the LSN of the clog page. (You seem to have it flushing through
> the last xlog record written by the backend, which is exactly what
> it doesn't need to do.) By extension, it should be OK to set INVALID
> (aborted) hint bits in a tuple header without any concerns about
> flushing.
Done
> The caching logic in TransactionGetCommitLSN is obviously broken.
Fixed
> Is there really a use-case for adding a pgstat counter for "guaranteed"
> transactions? That adds pgstat overhead, and bloats the patch
> noticeably, and I don't entirely see the value of it.
Removed
> There's some padding junk inserted in XLogCtlData, which as far as I
> recall was never discussed, and is certainly not an integral part of the
> delayed-commit feature. If you want that you should submit and defend
> it separately.
Done
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com