Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-docs-owner+M7826=pgsql+2Ddocs=arkaria.postgresql.org@postgresql.org>)
 id 1Vg3za-0001wN-BQ
 for pgsql-docs@arkaria.postgresql.org; Tue, 12 Nov 2013 02:46:14 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-docs-owner+M7826=pgsql+2Ddocs=arkaria.postgresql.org@postgresql.org>)
 id 1Vg3zZ-00086Q-QG
 for pgsql-docs@arkaria.postgresql.org; Tue, 12 Nov 2013 02:46:13 +0000
Received: from makus.postgresql.org ([2001:4800:7903:4::125])
 by malur.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <bruce@momjian.us>) id 1Vg3zZ-00085Q-0l
 for pgsql-docs@postgresql.org; Tue, 12 Nov 2013 02:46:13 +0000
Received: from momjian.us ([72.94.173.45])
 by makus.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <bruce@momjian.us>) id 1Vg3zW-00028H-C7
 for pgsql-docs@postgresql.org; Tue, 12 Nov 2013 02:46:12 +0000
Received: from bruce by momjian.us with local (Exim 4.72)
 (envelope-from <bruce@momjian.us>)
 id 1Vg3zV-0004nv-PM; Mon, 11 Nov 2013 21:46:09 -0500
Date: Mon, 11 Nov 2013 21:46:09 -0500
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-documentation <pgsql-docs@postgresql.org>
Subject: Re: MVCC snapshot timing
Message-ID: <20131112024609.GG15562@momjian.us>
References: <20131111175737.GA15562@momjian.us>
 <13024.1384202385@sss.pgh.pa.us>
 <20131111205833.GC15562@momjian.us>
 <20331.1384221575@sss.pgh.pa.us>
 <20131112021954.GD15562@momjian.us>
 <21328.1384223235@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="S1BNGpv0yoYahz37"
Content-Disposition: inline
In-Reply-To: <21328.1384223235@sss.pgh.pa.us>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-docs>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-docs.postgresql.org>
List-Owner: <mailto:pgsql-docs-owner@postgresql.org>
List-Post: <mailto:pgsql-docs@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-docs>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-docs>
X-Mailing-List: pgsql-docs
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org


--S1BNGpv0yoYahz37
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Nov 11, 2013 at 09:27:15PM -0500, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Mon, Nov 11, 2013 at 08:59:35PM -0500, Tom Lane wrote:
> >> 'Statement' might work.
> 
> > OK, updated patch attached.  Is "statement" too vague here?  SQL
> > statement?  query?
> 
> "SQL statement" might be a good idea in the first sentence, but
> I don't think you need to repeat it in the second.
> 
> What's bothering me about this wording is that you're talking about
> statements and then suddenly reference transactions (as being "those
> other things messing with your data").  This seems weirdly asymmetric,
> since after all you could equally well be the one messing with their
> data.

Yes, that bugged me too, but then I realized that you only see the
changes from a transaction when it completes, not from each statement,
e.g. you can never see changes between statements of a multi-statement
transaction.

I used "SQL statement" in the updated, attached patch.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

--S1BNGpv0yoYahz37
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="mvcc.diff"

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
new file mode 100644
index cefd323..f56eb55
*** a/doc/src/sgml/mvcc.sgml
--- b/doc/src/sgml/mvcc.sgml
***************
*** 41,52 ****
      for developers to manage concurrent access to data.  Internally,
      data consistency is maintained by using a multiversion
      model (Multiversion Concurrency Control, <acronym>MVCC</acronym>).
!     This means that while querying a database each transaction sees
      a snapshot of data (a <firstterm>database version</firstterm>)
      as it was some
      time ago, regardless of the current state of the underlying data.
!     This protects the transaction from viewing inconsistent data that
!     could be caused by (other) concurrent transaction updates on the same
      data rows, providing <firstterm>transaction isolation</firstterm>
      for each database session.  <acronym>MVCC</acronym>, by eschewing
      the locking methodologies of traditional database systems,
--- 41,52 ----
      for developers to manage concurrent access to data.  Internally,
      data consistency is maintained by using a multiversion
      model (Multiversion Concurrency Control, <acronym>MVCC</acronym>).
!     This means that each SQL statement sees
      a snapshot of data (a <firstterm>database version</firstterm>)
      as it was some
      time ago, regardless of the current state of the underlying data.
!     This prevents statements from viewing inconsistent data produced
!     by concurrent transactions performing updates on the same
      data rows, providing <firstterm>transaction isolation</firstterm>
      for each database session.  <acronym>MVCC</acronym>, by eschewing
      the locking methodologies of traditional database systems,

--S1BNGpv0yoYahz37
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

--S1BNGpv0yoYahz37--