Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZMDFG-00065w-Ef for pgsql-docs@arkaria.postgresql.org; Mon, 03 Aug 2015 10:45:26 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZMDFE-0008P7-Oi for pgsql-docs@arkaria.postgresql.org; Mon, 03 Aug 2015 10:45:24 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZMDFD-0008O7-Bj for pgsql-docs@postgresql.org; Mon, 03 Aug 2015 10:45:23 +0000 Received: from mail-io0-x22e.google.com ([2607:f8b0:4001:c06::22e]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ZMDEy-0005wH-Vp for pgsql-docs@postgresql.org; Mon, 03 Aug 2015 10:45:22 +0000 Received: by ioeg141 with SMTP id g141so140905189ioe.3 for ; Mon, 03 Aug 2015 03:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dFkuLrZ9oMWYkzcbBB3HoalIFL73QcqOJzDXWzW6rvU=; b=QOS6v3tHDUd6MInOCZjziG0YWsFaeJoEudT+AFSxl/3Nl0m+fLRlZUWc0jFXHSawg1 waKOFy2RlZcpgouOOqovADR5mJrnwx2vQ2vpx0xFy/IzKM4YNmUKKY9Kwe0ulxp7vTSh BeZjD08HZchpXIbe/InUeC9sLTYctt1gCr+6t/Cv4JBAdWRkNZlbt0Wn80HrA8oAAHri SXR9Rai9DhBnw2cy7Iazw5M3aLcTVWadf12vnoCt3pYU6FHa9obmuMmf56zAZtBVS+rF JqI1AlfZuqrJjJI5P9V08nZP+pPuy97t+hTE+H4mhVVlB9M8IKhyZMo/PUeEE8vhdM4d JBfA== MIME-Version: 1.0 X-Received: by 10.107.136.89 with SMTP id k86mr18886330iod.53.1438598705929; Mon, 03 Aug 2015 03:45:05 -0700 (PDT) Received: by 10.79.7.87 with HTTP; Mon, 3 Aug 2015 03:45:05 -0700 (PDT) In-Reply-To: <127576699.373753.1438565750177.JavaMail.yahoo@mail.yahoo.com> References: <127576699.373753.1438565750177.JavaMail.yahoo@mail.yahoo.com> Date: Mon, 3 Aug 2015 13:45:05 +0300 Message-ID: Subject: Re: Confused by example in 13.2.2 From: Dmitry Igrishin To: Kevin Grittner Cc: pgsql-docs Content-Type: multipart/alternative; boundary=001a1145a072d76776051c65dc50 X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org --001a1145a072d76776051c65dc50 Content-Type: text/plain; charset=UTF-8 2015-08-03 4:35 GMT+03:00 Kevin Grittner : > Dmitry Igrishin wrote: > > > I'm confused a bit by example in 13.2.2: > > In current docs that is the "Repeatable Read Isolation Level" > section. > > > "For example, even a read only transaction at this level may see a > > control record updated to show that a batch has been completed but > > not see one of the detail records which is logically part of the batch > > because it read an earlier revision of the control record." > > > > Could anyone clarify this example? And what is "control record"? > > Yeah, that sentence doesn't really have enough context. There was > discussion around this example in the Wiki: > > https://wiki.postgresql.org/wiki/SSI#Deposit_Report Thank you for the link! > > > ... and with that fresh in everyone's memory it seemed to make > sense at the time. Would this change make it clear to you?: > > "For example, you might have a workload involving batches, with a > control table having a record to describe the state of each batch > and another table with the detail; a read only transaction at this > isolation level could see a control record updated to show that a > batch has been completed but not see one of the detail records > which is logically part of the batch because the transaction > inserting the detail read an earlier version of the control > record." > Yes, it's clearer, but the following yet more clear to me: "For example, let you have table Receipt with batches and table Control with a single record pointing to the batch being processed currently. Let the transaction T1 inserts a records into Receipt. At about the same time transaction T2 updates the Control to start working with a new batch and commits. Next, the read only transaction T3 at this isolation level could see an updated by T2 record from Control but not see some records from Receipt which are part of the some batch, because the uncommitted transaction T1 has used earlier version of record from Control upon inserts." > > Hopefully the example from the Wiki makes it clear. There has been > some discussion about whether to link to the Wiki or bring an > example like that into the documentation; but we usually don't > link to Wiki pages and the example is somewhat long to include > in-line in the documentation. Any thoughts on the best solution to > that? > I've tried to adopt the example from Wiki above. Thanks! -- // Dmitry. --001a1145a072d76776051c65dc50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-08-03 4:35 GMT+03:00 Kevin Grittner <kgrittn@ymail.com>:
Dmitry Igrishin &= lt;dmitigr@gmail.com> wrote:
> I'm confused a bit by example in 13.2.2:

In current docs that is the "Repeatable Read Isolation Level&qu= ot;
section.

> "For example, even a read only transaction at this level may see = a
> control record updated to show that a batch has been completed but
> not see one of the detail records which is logically part of the batch=
> because it read an earlier revision of the control record."
>
> Could anyone clarify this example? And what is "control record&qu= ot;?

Yeah, that sentence doesn't really have enough context. There wa= s
discussion around this example in the Wiki:

https://wiki.postgresql.org/wiki/SSI#Deposit_Repo= rt
Thank you for the link!=C2=A0


... and with that fresh in everyone's memory it seemed to make
sense at the time. Would this change make it clear to you?:

"For example, you might have a workload involving batches, with a
control table having a record to describe the state of each batch
and another table with the detail; a read only transaction at this
isolation level could see a control record updated to show that a
batch has been completed but not see one of the detail rec= ords
which is logically part of the batch because the transaction
inserting the detail read an earlier version of the control
record."
Yes, it's clearer, but the following= yet more clear to me:
"For example, let you have table Rece= ipt with batches and table Control
with a single record pointing = to the batch being processed currently.
Let the transaction T1 in= serts a records into Receipt. At about the same time
transaction = T2 updates the Control to start working with a new batch and
comm= its. Next, the read only transaction T3 at this isolation level could see
an updated by T2 record from Control but not see some records from= Receipt which are part of the some batch, because the uncommitted transact= ion T1 has used earlier version of record from Control upon inserts."<= /div>

Hopefully the example from the Wiki makes it clear. There has been
some discussion about whether to link to the Wiki or bring an
example like that into the documentation; but we usually don't
link to Wiki pages and the example is somewhat long to include
in-line in the documentation. Any thoughts on the best solution to
that?
I've tried to adopt the example from Wiki ab= ove.

Thanks!

--
// Dmitr= y.

--001a1145a072d76776051c65dc50--