public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: Tom Lane <[email protected]>
Cc: PostgreSQL-documentation <[email protected]>
Subject: Re: MVCC snapshot timing
Date: Mon, 11 Nov 2013 21:19:54 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-docs>
On Mon, Nov 11, 2013 at 08:59:35PM -0500, Tom Lane wrote:
> Bruce Momjian <[email protected]> writes:
> > On Mon, Nov 11, 2013 at 03:39:45PM -0500, Tom Lane wrote:
> >> I'm not really seeing the point of s/transaction/session/ here.
>
> > Well, the problem with the original wording is that we don't take a new
> > snapshot for every transaction in the default read-committed mode.
>
> We take at least one snapshot per transaction, in any mode. Referring
> to sessions makes it even further away from being a useful concept.
>
> > Would you prefer I refer to statements, e.g.:
>
> 'Statement' might work.
OK, updated patch attached. Is "statement" too vague here? SQL
statement? query?
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Attachments:
[text/x-diff] mvcc.diff (1.7K, 2-mvcc.diff)
download | inline diff:
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
new file mode 100644
index cefd323..7d6e75b
*** 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 while querying a database each 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,
view thread (17+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: MVCC snapshot timing
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox