Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1stZNE-00HRoS-3I for pgsql-general@arkaria.postgresql.org; Wed, 25 Sep 2024 21:16:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1stZNC-00EVW8-3S for pgsql-general@arkaria.postgresql.org; Wed, 25 Sep 2024 21:16:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1stZNB-00EVW0-PC for pgsql-general@lists.postgresql.org; Wed, 25 Sep 2024 21:16:33 +0000 Received: from mail-oa1-x2e.google.com ([2001:4860:4864:20::2e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1stZN9-0013DY-3a for pgsql-general@postgresql.org; Wed, 25 Sep 2024 21:16:32 +0000 Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-27cecdc5098so233107fac.0 for ; Wed, 25 Sep 2024 14:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727298990; x=1727903790; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=GDL0TaojkttdfdNr/LJIxq719XfDhsvjZ+6BO4SVW+M=; b=KWAWsvSsEt91Kll5MZJ0s8TdVpCDM39l1hgv5e7MuwweWvVLsN6HbPsQoinXg4a4P5 UA2g91UEDEcqrjxSTE0u+7q3WB0tQS4gsgMQoF5Vl1Ga4ur587IhGdx6j/ch+IioNlZt eySJ4cjNWbUshRLzyqzTTobKy8YQAoF31s/8g+shcwUNPGJnWOijkwBeQ5YLZJ0tA1x+ DmNUmIl0WMXyuXeZAqdbNoo256yIWcsIDihkgG61lY1iNNaPDTZunEIeUcYFG25M4/J6 XQ1dWsVgZbQJkUhNlN4ahxsacut4XW6TkES0/R+qMNaMLdlKoTZHfEzSwUpSSBSJti1m gq5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727298990; x=1727903790; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GDL0TaojkttdfdNr/LJIxq719XfDhsvjZ+6BO4SVW+M=; b=fj29NIBLHA4bYSL1tjK1/mUEDSpEx7odPtqn8364iCox79BbhLKR8ugSfOKISDpu0t cw6eAs9c7Juxly3ILBhXmKlyfd622TPkJ5yALM4gKxrKpX+42dzHnwNVg0E4Ul28q3zM 85xj4crS8RwJO2CZtQNQQM5b8eU1WZgtufd/o9Zqmn5Ie3w0b3V/tz+cRFd9TPNEy0fK CWaEonX2UqGRCAkL7T/qguRwcZbmn9fcZZauGFF8k2DybcTUBuka8D5/RR2FklD6fakq oWuvYeNRuMxXaVJzQmyYe39Ti2Tk1rZtLxfARj3e65epvtOyaF2X4pehkHhDemDQP1aN bIbA== X-Gm-Message-State: AOJu0Yyj4uUrrdSZUzc9jRa5bwi1cdww/8GfY3u03tv+7FJcK2K0o45s VfFLaQZYcsSIfMiV2+AVT52caX1aMR6qvCSXPCsZLih+7RTQoTfwVVWZoT5HcSEe8g6BWdNWr9+ 32FeHRic0BeFXFV1nEkwBAwEHFahhvw== X-Google-Smtp-Source: AGHT+IGr0mCH5n/DgLPnSFvoR4AGUue30fuW9D19AVfqtUIMAPSTXTO82VhIJ7MMpaF/217TN4Q+3oIWPw8eGfHxU+s= X-Received: by 2002:a05:6871:e015:b0:278:978:9e9 with SMTP id 586e51a60fabf-286e176090emr3665515fac.44.1727298990217; Wed, 25 Sep 2024 14:16:30 -0700 (PDT) MIME-Version: 1.0 References: <9CEBFAC7-4372-4FF0-8124-FFFE834B03C6@gmail.com> <3346993.1727188126@sss.pgh.pa.us> <28109.1727286817@sss.pgh.pa.us> In-Reply-To: From: Ron Johnson Date: Wed, 25 Sep 2024 17:16:19 -0400 Message-ID: Subject: Re: Repeatable Read Isolation Level "transaction start time" To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000bba4150622f8229c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000bba4150622f8229c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 25, 2024 at 4:50=E2=80=AFPM Greg Sabino Mullane wrote: > Since transactions should be "as short as possible, without being too >>> short", how much time is there between when you run "BEGIN;" and the fi= rst >>> "work statement"? >>> >> > I don't know that it really matters. For something automated, it would be > a few milliseconds. > That's what I'm thinking, too. It might cause a problem if you're typing transaction commands in between drinking coffee and poking around other PgAdmin tabs, but that's *your* fault, not PG's fault. > Either way, I'm sure most people/apps already think of the initial 'BEGIN > ...' as the start of the transaction, and act accordingly. > > Maybe long-term something like > > BEGIN ISOLATION MODE REPEATABLE READ SNAPSHOT NOW; > Without the "NOW", that's essentially the command used by the legacy rdbms which I used to work on. I'm trying to remember, though, if "SET TRANSACTION READ WRITE RESERVING foo FOR ;" (it's syntax for beginning a transaction) started the transaction, or waited until an "action" statement. Been too long. --=20 Death to , and butter sauce. Don't boil me, I'm still alive. crustacean! --000000000000bba4150622f8229c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Sep 25, 2024 at 4:50=E2=80=AFPM G= reg Sabino Mullane <htamfids@gmail= .com> wrote:
Since transactions should be "= as short as possible, without being too short", how much time is there= between when you run "BEGIN;" and the first "work statement= "?

I don't know that it really matters. For something automated, it woul= d be a few milliseconds.

= That's what I'm thinking, too.=C2=A0 It might cause a problem if yo= u're typing transaction commands in between=C2=A0drinking coffee and po= king around other PgAdmin tabs, but that's your=C2=A0fault, not = PG's fault.
=C2=A0
Either way, = I'm sure most people/apps already think of the initial 'BEGIN ...&#= 39; as the=C2=A0start of the transaction, and act accordingly.
Maybe long-term something like

BEGIN= =C2=A0 =C2=A0ISOLATION MODE REPEATABLE READ=C2=A0 =C2=A0SNAPSHOT NOW;
=

Without the "NOW", t= hat's essentially the command used by the legacy rdbms which I used to = work on.

I'm trying to remember, though,= if "SET TRANSACTION READ WRITE RESERVING foo FOR <isolation level&= gt;;" (it's syntax for beginning a transaction) started the transa= ction, or waited until an "action" statement.=C2=A0 Been too long= .

--
=
Death to <Re= dacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> crustacean!
--000000000000bba4150622f8229c--