Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nophX-0000on-MW for pgsql-docs@arkaria.postgresql.org; Wed, 11 May 2022 17:00:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nophW-0003Ke-7q for pgsql-docs@arkaria.postgresql.org; Wed, 11 May 2022 17:00:38 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nophV-0003KU-US for pgsql-docs@lists.postgresql.org; Wed, 11 May 2022 17:00:38 +0000 Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nophR-00066R-Ja for pgsql-docs@lists.postgresql.org; Wed, 11 May 2022 17:00:37 +0000 Received: by mail-ej1-x630.google.com with SMTP id i27so5293147ejd.9 for ; Wed, 11 May 2022 10:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=KqUmj6uH6tWPy3pgCgNd/e6bcdtglewdoc22axHxvtY=; b=UFRwjqOhxl8r0mkwrzRQPAPBkEV8emPKKSlVtsn9+KvxnYhAeuPvWwgGwh/J42cLdo C9iNljehNMeIagMkNsasD+Qw54/40RY2vRlsryq2VmtUGDHNxHc0tv3rxm6Ol22U6+yu a6vwRV72iUe/p3o00FyMYa//r6TjSuxphHkqGCVdqU5L3gMN5Lj2bGCcp/lonZzTQXr3 DJZACHeRaLBafYnxf1M6iWGHKc44fOlZAtSsEpllbAsB7XJsung5h7dIEGCpXHJk5pnG gyepgkOoaT5UIjlyhlPJR+vICuZndJT5lqgpeTUxWOWeM/Prpio4NorudOo1TEM8Gp5U +V5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=KqUmj6uH6tWPy3pgCgNd/e6bcdtglewdoc22axHxvtY=; b=Xq4u/v2tFuAVA8fh9MseuyG5F2hvpUuLtE9DnnBmnAxJdtO5QgVvFGrp7lXMRCc2rq lY9n/V00pFMkgvoDbHRArcAgMr2hgsvwi4qgYb5j8drH/u/W5jWWT32bnoiP2fUeHo8e EUQ2nILM6PO5HJtHgTeIilu27skFGYssQhOqBg+kjjnipqgbJYKlJWSpBPdN2yvhQHHw 30dg6yE3zp8ubFujrNM2Ci9A06UDYh0GzMnXFGNeKIRWttAsGLH4KLO8vMk6V5N8Afqm D8cWiNyMWkmfcSVj9jMAkbVsQYxozPg2dD50abQDlJVWG9FDaWmF2IBNwmW7h5ydeLkY PzzQ== X-Gm-Message-State: AOAM533WdxKtHltiZthJ2uKi95HduMsO+q50iJ8MJMPweK6yE4Zb17jQ V8IT8qu0Z12DcZIAXixypPX8DZjyeLQSunquss4= X-Google-Smtp-Source: ABdhPJysKyAT0bY5jnJUo5X6IToqFYu+IB9EsIkZLzIAk0DnLQIAWW0j1RgipIcMkrMDGIAR8c1D+Q+sFRJR6xCrZ2w= X-Received: by 2002:a17:906:c14c:b0:6f4:fdf3:4a3a with SMTP id dp12-20020a170906c14c00b006f4fdf34a3amr25561756ejc.525.1652288432239; Wed, 11 May 2022 10:00:32 -0700 (PDT) MIME-Version: 1.0 References: <165227672089.669.4147837796611036970@wrigleys.postgresql.org> In-Reply-To: <165227672089.669.4147837796611036970@wrigleys.postgresql.org> From: "David G. Johnston" Date: Wed, 11 May 2022 10:00:15 -0700 Message-ID: Subject: Re: SET TRANSACTION SNAPSHOT sounds like replicated environment but isn't To: maweki@gmail.com, Pg Docs Content-Type: multipart/alternative; boundary="00000000000011fafe05debf6180" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000011fafe05debf6180 Content-Type: text/plain; charset="UTF-8" On Wed, May 11, 2022 at 7:33 AM PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/14/sql-set-transaction.html > Description: > > Hello, > > the wording on the SET TRANSACTION SNAPSHOT left me a bit confused. It says > "To begin a new transaction with the same snapshot as an already existing > transaction" and it feels like basically taking over an existing > session/transaction or being able to replicate a transaction from that > snapshot on. > I'm not sure what a final documentation patch might look like but this section can rightfully assume some prior knowledge about how the system works with regards to snapshots. In particular, a snapshot is effectively a single value that a session maintains that lets it compute whether a given transaction id is visible or not. So, "whenever you give me data only do so up to this point-in-time". Understanding that dynamic should lead one to conclude that just having a shared since of "point-in-time" doesn't have anything to do with permissions to interact with specific objects in the first place. And, for temporary tables, to break the session isolation that it is assumed the reader is aware of. David J. --00000000000011fafe05debf6180 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 11, 2022 at 7:33 AM PG Doc comments form <<= a href=3D"mailto:noreply@postgresql.org">noreply@postgresql.org> wro= te:
The following documentation comment has been lo= gged on the website:

Page: https://www.postgresql.org/docs/14/= sql-set-transaction.html
Description:

Hello,

the wording on the SET TRANSACTION SNAPSHOT left me a bit confused. It says=
"To begin a new transaction with the same snapshot as an already exist= ing
transaction" and it feels like basically taking over an existing
session/transaction or being able to replicate a transaction from that
snapshot on.

I'm not sure what a fina= l documentation patch might look like but this section can rightfully assum= e some prior knowledge about how the system works with regards to snapshots= .=C2=A0 In particular, a snapshot is effectively a single value that a sess= ion maintains that lets it compute whether a given transaction id is visibl= e or not.=C2=A0 So, "whenever you give me data only do so up to this p= oint-in-time".=C2=A0 Understanding that dynamic should lead one to con= clude that just having a shared since of "point-in-time" doesn= 9;t have anything to do with permissions to interact with specific objects = in the first place.=C2=A0 And, for temporary tables, to break the session i= solation that it is assumed the reader is aware of.

Da= vid J.

--00000000000011fafe05debf6180--