David Fetter <david(at)fetter(dot)org> wrote:
> That it's not ready for commit this minute does not mean that it
> shouldn't be in the CF this month. Delaying the first review of
> the patch until the next CF pretty much ensures that we'll miss
> 9.1 with it, so please add to the current CF :)
Well, I had a version which compiled without warning and passed the
regular regression tests before the deadline, but it would have been
rather disingenuous to post it. I'm in the middle of reworking the
guts of it and there's a lot of wet paint at the moment. Most of
the dcheck tests are failing, which isn't a surprise because I
haven't finished re-implementing everything which was working before
this weekend. I'm not sure what a reviewer could say right now
other than to point out all the loose ends fluttering in the breeze.
To be clear -- before this weekend I had something which worked
correctly in all respects except, as pointed out by Heikki and Jeff,
it was vulnerable to filling its in-memory structures if there was a
long-running transaction concurrent with a lot of short-lived
transactions. At that point the only options, as the patch stood,
were to refuse to start new serializable transactions or to start
killing off the oldest active serializable transactions.
This issue has been on the Wiki page as an R&D "What should we do
about this?" item since the 25th of January, but it took the
discussion around the review in the last CF to lead to a design for
a solution. Then my father landed in the hospital after a cardiac
arrest, an in-law died, and I got a nasty toothache which ultimately
needed a root canal last week. On top of that, I've been assigned
some high priority tasks at work which relegate work on this patch
to nights and weekends for the time being. Dan has also been
unavailable, although for happier reasons -- he got married and took
a vacation. Overall, though, a tough few weeks for making progress
on implementing the designed solution.
It's likely to be two to four weeks before I have something in a
condition which it would make sense for anyone to spend time on.
Anyone who wants to watch the progress is welcome to track the git
repo. I pushed this weekend's work in this commit, wet paint and
all:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=208ade2acb6c34177c4bfd49e1f240fb751b8be1
That went in an hour and a half before the CF deadline, but I just
didn't feel right putting it into the CF in that shape. I'm most of
the way through replacing the conflict pointers with conflict lists,
which I decided was a prerequisite for solving the memory management
issues in an effective way. I have yet to start work on the memory
management issues themselves.
-Kevin