Jeff Davis wrote: > 1. In CheckForSerializableConflictIn(), I think the comment above > may be out of date. It says: > 2. Also in the comment above CheckForSerializableConflictIn(), I > see: > 3. The comment above CheckForSerializableConflictOut() seems to > trail off, as though you may have meant to write more. It also > seems to be out of date. Will fix and post a patch version 15, along with the other fixes based on feedback to v14 (mostly to comments and docs) within a few hours. I'll also do that global change from using "tran" as an abbreviation for transaction in some places to consistently using xact whenever it is abbreviated. > And why are you reading the infomask directly? Do the existing > visibility functions not suffice? It's possible we re-invented some code somewhere, but I'm not clear on what code from this patch might use what existing function. Could you provide specifics? > I have made it through predicate.c, and I have a much better > understanding of what it's actually doing. I can't claim that I > have a clear understanding of everything involved, but the code > looks like it's in good shape (given the complexity involved) and > well-commented. Thanks! I know that's a lot of work, and I appreciate you pointing out where comments have not kept up with coding. > I am marking the patch Ready For Committer, because any committer > will need time to go through the patch; and the authors have > clearly applied the thought, care, and testing required for > something of this complexity. I will continue to work on it, > though. Thanks! > The biggest issue on my mind is what to do about Hot Standby. The > authors have a plan, but there is also some resistance to it: > > http://archives.postgresql.org/message-id/23698.1295566...@sss.pgh.pa.us > > We don't need a perfect solution for 9.1, but it would be nice if > we had a viable plan for 9.2. I don't recall any real opposition to what I sketched out in this post, which came after the above-referenced one: http://archives.postgresql.org/message-id/4d39d5ec0200002500039...@gw.wicourts.gov Also, that opposition appears to be based on a misunderstanding of the first alternative, which was for sending at most one snapshot per commit or rollback of a serializable read write transaction, with possible throttling. The alternative needs at most two bits per commit or rollback of a serializable read write transaction; although I haven't checked whether that can be scared up without adding a whole byte. Read only transactions have nothing to do with the traffic under either alternative. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
