Jonah H. Harris wrote:
Looking forward, if no one
wanted to review these patches in November,
I did, and many others were active in the discussion too.
and seemingly no one wants to review them now,
I do. Thank you for your appreciation :-(.
how can we expect this to change for 8.5? Can anyone point
out something Simon did wrong in this process?
Not really, except maybe started 6 months too late. Big patches simply
take a long time to mature.
Looking back at the timeline for hot standby, it doesn't look
unreasonable at all:
September: First discussion about the user-visible behavior, transaction
isolation etc. Big architectural decisions are made, like where that
snapshots are taken. "Infrastructure changes for recovery" patch is
reviewed, and pushed to next commitfest because of issues. Discussion
started on how to handle (heavy-weight) locks.
October: Discussion on various administration commands, how to handle
b-tree splits, and some other stuff. More discussion on how to derive
snapshots. First complete hot standby patch is submitted. A patch to
change the way subtransactions is submitted, and committed.
November: Various people test and review the patch, including Mark
Kirkwood and Pavan Deolasee. Bugs are found and fixed. Decision is made
that SIGINT should kill an idle-in-transaction transaction as well.
December: Discussion on slotids and the B-tree killed items problem.
January: Major changes; slotids eliminated, conflict resolution
mechanism rewritten. RestoreBkpBlocks refactoring committed. More bugs
in conflict resolution unearthed. Discussion on adding a GUC.
There has been steady progress, starting from basic design discussions
and decisions, moving on to implementation details. Progress never
stalled for a long time. I can see no wrongdoing on Simon's part, and
there is also no grounds to say that the community has neglected this patch.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
