I686LINUX/util/I686LINUX/doc/postgresql/html/applevel-consistency.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
   2 <HTML
   3 ><HEAD
   4 ><TITLE
   5 >Data Consistency Checks at the Application Level</TITLE
   6 ><META
   7 NAME="GENERATOR"
   8 CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
   9 REV="MADE"
  10 HREF="mailto:pgsql-docs@postgresql.org"><LINK
  11 REL="HOME"
  12 TITLE="PostgreSQL 7.4.1 Documentation"
  13 HREF="index.html"><LINK
  14 REL="UP"
  15 TITLE="Concurrency Control"
  16 HREF="mvcc.html"><LINK
  17 REL="PREVIOUS"
  18 TITLE="Explicit Locking"
  19 HREF="explicit-locking.html"><LINK
  20 REL="NEXT"
  21 TITLE="Locking and Indexes"
  22 HREF="locking-indexes.html"><LINK
  23 REL="STYLESHEET"
  24 TYPE="text/css"
  25 HREF="stylesheet.css"><META
  26 NAME="creation"
  27 CONTENT="2003-12-22T03:48:47"></HEAD
  28 ><BODY
  29 CLASS="SECT1"
  30 ><DIV
  31 CLASS="NAVHEADER"
  32 ><TABLE
  33 SUMMARY="Header navigation table"
  34 WIDTH="100%"
  35 BORDER="0"
  36 CELLPADDING="0"
  37 CELLSPACING="0"
  38 ><TR
  39 ><TH
  40 COLSPAN="5"
  41 ALIGN="center"
  42 VALIGN="bottom"
  43 >PostgreSQL 7.4.1 Documentation</TH
  44 ></TR
  45 ><TR
  46 ><TD
  47 WIDTH="10%"
  48 ALIGN="left"
  49 VALIGN="top"
  50 ><A
  51 HREF="explicit-locking.html"
  52 ACCESSKEY="P"
  53 >Prev</A
  54 ></TD
  55 ><TD
  56 WIDTH="10%"
  57 ALIGN="left"
  58 VALIGN="top"
  59 ><A
  60 HREF="mvcc.html"
  61 >Fast Backward</A
  62 ></TD
  63 ><TD
  64 WIDTH="60%"
  65 ALIGN="center"
  66 VALIGN="bottom"
  67 >Chapter 12. Concurrency Control</TD
  68 ><TD
  69 WIDTH="10%"
  70 ALIGN="right"
  71 VALIGN="top"
  72 ><A
  73 HREF="mvcc.html"
  74 >Fast Forward</A
  75 ></TD
  76 ><TD
  77 WIDTH="10%"
  78 ALIGN="right"
  79 VALIGN="top"
  80 ><A
  81 HREF="locking-indexes.html"
  82 ACCESSKEY="N"
  83 >Next</A
  84 ></TD
  85 ></TR
  86 ></TABLE
  87 ><HR
  88 ALIGN="LEFT"
  89 WIDTH="100%"></DIV
  90 ><DIV
  91 CLASS="SECT1"
  92 ><H1
  93 CLASS="SECT1"
  94 ><A
  95 NAME="APPLEVEL-CONSISTENCY"
  96 >12.4. Data Consistency Checks at the Application Level</A
  97 ></H1
  98 ><P
  99 >    Because readers in <SPAN
 100 CLASS="PRODUCTNAME"
 101 >PostgreSQL</SPAN
 102 >
 103     do not lock data, regardless of
 104     transaction isolation level, data read by one transaction can be
 105     overwritten by another concurrent transaction. In other words,
 106     if a row is returned by <TT
 107 CLASS="COMMAND"
 108 >SELECT</TT
 109 > it doesn't mean that
 110     the row is still current at the instant it is returned (i.e., sometime
 111     after the current query began).  The row might have been modified or
 112     deleted by an already-committed transaction that committed after this one
 113     started.
 114     Even if the row is still valid <SPAN
 115 CLASS="QUOTE"
 116 >"now"</SPAN
 117 >, it could be changed or
 118     deleted
 119     before the current transaction does a commit or rollback.
 120    </P
 121 ><P
 122 >    Another way to think about it is that each
 123     transaction sees a snapshot of the database contents, and concurrently
 124     executing transactions may very well see different snapshots.  So the
 125     whole concept of <SPAN
 126 CLASS="QUOTE"
 127 >"now"</SPAN
 128 > is somewhat suspect anyway.
 129     This is not normally
 130     a big problem if the client applications are isolated from each other,
 131     but if the clients can communicate via channels outside the database
 132     then serious confusion may ensue.
 133    </P
 134 ><P
 135 >    To ensure the current validity of a row and protect it against
 136     concurrent updates one must use <TT
 137 CLASS="COMMAND"
 138 >SELECT FOR
 139     UPDATE</TT
 140 > or an appropriate <TT
 141 CLASS="COMMAND"
 142 >LOCK TABLE</TT
 143 >
 144     statement.  (<TT
 145 CLASS="COMMAND"
 146 >SELECT FOR UPDATE</TT
 147 > locks just the
 148     returned rows against concurrent updates, while <TT
 149 CLASS="COMMAND"
 150 >LOCK
 151     TABLE</TT
 152 > locks the whole table.)  This should be taken into
 153     account when porting applications to
 154     <SPAN
 155 CLASS="PRODUCTNAME"
 156 >PostgreSQL</SPAN
 157 > from other environments.
 158     (Before version 6.5 <SPAN
 159 CLASS="PRODUCTNAME"
 160 >PostgreSQL</SPAN
 161 > used
 162     read locks, and so this above consideration is also relevant when
 163     upgrading from <SPAN
 164 CLASS="PRODUCTNAME"
 165 >PostgreSQL</SPAN
 166 > versions
 167     prior to 6.5.)
 168    </P
 169 ><P
 170 >    Global validity checks require extra thought under <ACRONYM
 171 CLASS="ACRONYM"
 172 >MVCC</ACRONYM
 173 >.  For
 174     example, a banking application might wish to check that the sum of
 175     all credits in one table equals the sum of debits in another table,
 176     when both tables are being actively updated.  Comparing the results of two
 177     successive <TT
 178 CLASS="LITERAL"
 179 >SELECT sum(...)</TT
 180 > commands will not work reliably under
 181     Read Committed mode, since the second query will likely include the results
 182     of transactions not counted by the first.  Doing the two sums in a
 183     single serializable transaction will give an accurate picture of the
 184     effects of transactions that committed before the serializable transaction
 185     started --- but one might legitimately wonder whether the answer is still
 186     relevant by the time it is delivered.  If the serializable transaction
 187     itself applied some changes before trying to make the consistency check,
 188     the usefulness of the check becomes even more debatable, since now it
 189     includes some but not all post-transaction-start changes.  In such cases
 190     a careful person might wish to lock all tables needed for the check,
 191     in order to get an indisputable picture of current reality.  A
 192     <TT
 193 CLASS="LITERAL"
 194 >SHARE</TT
 195 > mode (or higher) lock guarantees that there are no
 196     uncommitted changes in the locked table, other than those of the current
 197     transaction.
 198    </P
 199 ><P
 200 >    Note also that if one is
 201     relying on explicit locks to prevent concurrent changes, one should use
 202     Read Committed mode, or in Serializable mode be careful to obtain the
 203     lock(s) before performing queries.  An explicit lock obtained in a
 204     serializable transaction guarantees that no other transactions modifying
 205     the table are still running, but if the snapshot seen by the
 206     transaction predates obtaining the lock, it may predate some now-committed
 207     changes in the table.  A serializable transaction's snapshot is actually
 208     frozen at the start of its first query or data-modification command
 209     (<TT
 210 CLASS="LITERAL"
 211 >SELECT</TT
 212 >, <TT
 213 CLASS="LITERAL"
 214 >INSERT</TT
 215 >,
 216     <TT
 217 CLASS="LITERAL"
 218 >UPDATE</TT
 219 >, or <TT
 220 CLASS="LITERAL"
 221 >DELETE</TT
 222 >), so
 223     it's possible to obtain explicit locks before the snapshot is
 224     frozen.
 225    </P
 226 ></DIV
 227 ><DIV
 228 CLASS="NAVFOOTER"
 229 ><HR
 230 ALIGN="LEFT"
 231 WIDTH="100%"><TABLE
 232 SUMMARY="Footer navigation table"
 233 WIDTH="100%"
 234 BORDER="0"
 235 CELLPADDING="0"
 236 CELLSPACING="0"
 237 ><TR
 238 ><TD
 239 WIDTH="33%"
 240 ALIGN="left"
 241 VALIGN="top"
 242 ><A
 243 HREF="explicit-locking.html"
 244 ACCESSKEY="P"
 245 >Prev</A
 246 ></TD
 247 ><TD
 248 WIDTH="34%"
 249 ALIGN="center"
 250 VALIGN="top"
 251 ><A
 252 HREF="index.html"
 253 ACCESSKEY="H"
 254 >Home</A
 255 ></TD
 256 ><TD
 257 WIDTH="33%"
 258 ALIGN="right"
 259 VALIGN="top"
 260 ><A
 261 HREF="locking-indexes.html"
 262 ACCESSKEY="N"
 263 >Next</A
 264 ></TD
 265 ></TR
 266 ><TR
 267 ><TD
 268 WIDTH="33%"
 269 ALIGN="left"
 270 VALIGN="top"
 271 >Explicit Locking</TD
 272 ><TD
 273 WIDTH="34%"
 274 ALIGN="center"
 275 VALIGN="top"
 276 ><A
 277 HREF="mvcc.html"
 278 ACCESSKEY="U"
 279 >Up</A
 280 ></TD
 281 ><TD
 282 WIDTH="33%"
 283 ALIGN="right"
 284 VALIGN="top"
 285 >Locking and Indexes</TD
 286 ></TR
 287 ></TABLE
 288 ></DIV
 289 ></BODY
 290 ></HTML
 291 >