On 15.01.2012 06:49, Alvaro Herrera wrote:
--- 164,178 ----
  #define HEAP_HASVARWIDTH              0x0002  /* has variable-width 
attribute(s) */
  #define HEAP_HASEXTERNAL              0x0004  /* has external stored 
attribute(s) */
  #define HEAP_HASOID                           0x0008  /* has an object-id 
field */
! #define HEAP_XMAX_KEYSHR_LOCK 0x0010  /* xmax is a key-shared locker */
  #define HEAP_COMBOCID                 0x0020  /* t_cid is a combo cid */
  #define HEAP_XMAX_EXCL_LOCK           0x0040  /* xmax is exclusive locker */
! #define HEAP_XMAX_IS_NOT_UPDATE       0x0080  /* xmax, if valid, is only a 
locker.
!                                                                               
 * Note this is not set unless
!                                                                               
 * XMAX_IS_MULTI is also set. */
!
! #define HEAP_LOCK_BITS        (HEAP_XMAX_EXCL_LOCK | HEAP_XMAX_IS_NOT_UPDATE 
| \
!                                                HEAP_XMAX_KEYSHR_LOCK)
  #define HEAP_XMIN_COMMITTED           0x0100  /* t_xmin committed */
  #define HEAP_XMIN_INVALID             0x0200  /* t_xmin invalid/aborted */
  #define HEAP_XMAX_COMMITTED           0x0400  /* t_xmax committed */

HEAP_XMAX_IS_NOT_UPDATE is a pretty opaque name for that. From the name, I'd say that a DELETE would set that, but the comment says it has to do with locking. After going through all the combinations in my mind, I think I finally understood it: HEAP_XMAX_IS_NOT_UPDATE is set if xmax is a multi-xact, that represent only locking xids, no updates. How about calling it "HEAP_XMAX_LOCK_ONLY", and setting it whenever whether or not xmax is a multi-xid?

- I haven't done anything about exposing FOR KEY UPDATE to the SQL
level.  There clearly isn't consensus about exposing this; in fact
there isn't consensus on exposing FOR KEY SHARE, but I haven't
changed that from the previous patch, either.

I think it would be useful to expose it. Not that anyone should be using
them in an application (or would it be useful?), but I feel it could
make testing significantly easier.

- pg_upgrade bits are missing.

I guess we'll need to rewrite pg_multixact contents in pg_upgrade. Is the page format backwards-compatible?

Why are you renaming HeapTupleHeaderGetXmax() into HeapTupleHeaderGetRawXmax()? Any current callers of HeapTupleHeaderGetXmax() should already check that HEAP_XMAX_IS_MULTI is not set.

--
  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

Reply via email to