Re: WIP patch for serializable transactions with predicate locking

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pgsql-hackers(at)postgresql(dot)org>
Cc: "Dan Ports" <drkp(at)csail(dot)mit(dot)edu>
Subject: Re: WIP patch for serializable transactions with predicate locking
Date: 2010-07-09 18:49:50
Message-ID: 4C3728FE0200002500033336@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Attached is an updated patch to correct for bitrot and include the
latest work.

Whoever reviews this will probably want to review the Serializable
Wiki page:

http://wiki.postgresql.org/wiki/Serializable

Some areas on which I would particularly appreciate feedback in the
initial review:

CODE ORGANIZATION: I started with predicate.c based on the lock.c
code, and so fell into the src/backend/storage/lmgr directory. It
has morphed into something which probably doesn't belong in that
directory, but I'm not sure where it *does* belong. An argument
could be made that the SSI logic should be split from the predicate
locking, except that there is so little code that isn't part of
tracking the predicate locks and their conflicts, I'm not sure about
that either. In a similar vein, the structures in predicate.h are
used in exactly one place outside of predicate.c; it might make
sense to split that .h file so that most places only bring in the
function prototypes, which is all they need. Or perhaps the code
added to lockfuncs.c should be moved to the new predicate.c file,
and called from lockfuncs.c?

NAMING: The names in predicate.c are somewhat inconsistent, and a
few of them outright annoy me -- particularly MyXxx in a structure
field. I want to do a pass to make the names more consistent, but
would appreciate any feedback on what's good, bad, or ugly in the
current code before I do.

CORNER CASES: What did we forget to handle?

-Kevin

Attachment Content-Type Size
serializable-2.patch text/plain 192.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-07-09 19:03:46 Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
Previous Message Simon Riggs 2010-07-09 18:17:36 Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().