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 1nx1I2-0002gC-N0 for pgsql-docs@arkaria.postgresql.org; Fri, 03 Jun 2022 07:00:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nx1I0-0000sR-Ie for pgsql-docs@arkaria.postgresql.org; Fri, 03 Jun 2022 07:00:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nx1Hz-0000sH-VS for pgsql-docs@lists.postgresql.org; Fri, 03 Jun 2022 07:00:08 +0000 Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nx1Hu-0004uV-HR for pgsql-docs@lists.postgresql.org; Fri, 03 Jun 2022 07:00:06 +0000 Received: by mail-ej1-x629.google.com with SMTP id v1so3472567ejg.13 for ; Fri, 03 Jun 2022 00:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pc4Ph40IpL7UYo5cgMZFqhMuu9yMwx+WVt8cVdknSQs=; b=cvM0oSecrxLB2+7SOM/cGXI2/uMsJP4RvgMjvhBIqkbuRrOfbKq1kh8XPSv/dBelmv 9BCrKzGzTsFxYMuZoVaZQmf7W5Hct1Z9UnyU9Zv1gFrmHZH/DboJUeXKqjyhaR6OQJJf 2De9+frkK/jsDJfW1ZOJIC5yC5GPK+MpNxw0Ptdssbwv9yalHBov1ZSfuFAd71Xt3q1Z lM3gkZYriUSNX2+jXCitfMnZlkAtVxzh255jyVQBpJg5YAnEklGvJ63//G00Ua8OoRID CC/1BHR/7ZArItFT99jQlUjm/cz8WQpFV8hw5M5fOrJtpkM+gpHRJmD6DeRVf/HqEXA3 mhXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pc4Ph40IpL7UYo5cgMZFqhMuu9yMwx+WVt8cVdknSQs=; b=ZBjqAj4qyKvg1BWQv1Hbp9pCvCuI7R0qjTMg4By3avjD0LlCDrZvDRfvN/jGi+/zlO jEpXpOFX06OMCD7NY3c9V25QhQ+Q53Hry47ATDq8Yuy1jg0S993skw8rwq+SHFZN2Fd5 MvFv6reUN2twcpUhCch98/8qgBJbzfUXRgBbT/LEW7ysOsW8TEjpNm1BnOa3iLFhTkAb KLu+HpDq/0PTXHb0pwwhV1vD7cNt5o9z4Ji/yI2nwDUbEL8mUpeto8mw2dtBIylKmZ6G Y+YkIUQv6hcxutlsfxMBFyTRVVUJL/pHBTuLxnk/77q7NgnkKsUD+IkI5DvktdStrVYC pJiA== X-Gm-Message-State: AOAM533ixck9nsEUNJt0/p5iWskaWNCWnVERkjAyKFJYPp80C6ozloh7 3aRPV6s9N/vTsZEeXFDuRsZhaMFG+TXDNskyphV4abrKqIU= X-Google-Smtp-Source: ABdhPJzjOwUdQpwkeQrxcSjNMZqF1X/fhqtVlyoLtxrwG0+bncFjFDEPGGqZdu0xnVjdNHwpJl3ENwgyFonaOBf1DBo= X-Received: by 2002:a17:907:9607:b0:6ff:14f6:c301 with SMTP id gb7-20020a170907960700b006ff14f6c301mr7293423ejc.525.1654239600194; Fri, 03 Jun 2022 00:00:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:640c:1fcc:b0:165:a4f7:ea4a with HTTP; Thu, 2 Jun 2022 23:59:59 -0700 (PDT) In-Reply-To: References: From: "David G. Johnston" Date: Thu, 2 Jun 2022 23:59:59 -0700 Message-ID: Subject: Re: pg_stat_database view column xact_commit description should be more descriptive? To: jian he Cc: "pgsql-docs@lists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000be3aab05e085ab15" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000be3aab05e085ab15 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thursday, June 2, 2022, jian he wrote: > > https://www.postgresql.org/docs/current/monitoring-stats. > html#MONITORING-PG-STAT-DATABASE-VIEW > >> xact_commit bigint >> >> Number of transactions in this database that have been committed >> > In https://www.postgresql.org/docs/current/sql-begin.html > > BEGIN initiates a transaction block, that is, all statements after a BEGI= N >> command will be executed in a single transaction until an explicit COMMI= T >> or ROLLBACK >> is given. By >> default (without BEGIN), PostgreSQL executes transactions in =E2=80=9Cau= tocommit=E2=80=9D >> mode, that is, each statement is executed in its own transaction and a >> commit is implicitly performed at the end of the statement (if execution >> was successful, otherwise a rollback is done). >> > > I guess the pg_stat_database view column *xact_commit *refers to > 'non-autocommit' transactions? > If so, should we say something like "Number of autocommit > transactions...." > My guess is that it doesn=E2=80=99t matter if it=E2=80=99s implicit or expl= icit and thus the documentation is correct and adequate. It does seem easy enough to prove one way or the other if you think it might be incorrect and thus to warrant a change to the docs. If it does vary I=E2=80=99d have reason to = suspect that a pure select query would exhibit different behavior than an insert or delete query - i.e., whether a new xid is issued makes a difference. I may experiment myself when I=E2=80=99m back at a computer but as you are = raising the potential issue the research seems like something that should be done to support the suggestion. It isn=E2=80=99t like this will require source = code reading to discern. David J. --000000000000be3aab05e085ab15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thursday, June 2, 2022, jian he <jian.universality@gmail.com> wrote:

xact_commit bigint

Number of transactions in this database that h= ave been committed

=20

BEGIN initiates a transaction block, that is, all statements a= fter a BEGIN command will be executed in a single transaction = until an explicit COMMIT or ROLLBACK is given. By default (without BEGIN), PostgreSQL executes transactions in =E2=80=9Cautocommit=E2=80=9D mode, that is, each statement is executed in its own transaction and a=20 commit is implicitly performed at the end of the statement (if execu= tion was successful, otherwise a rollback is done).

I guess the pg_stat_database view column xact_commit = refers to 'non-autocommit' transactions?
If so, should w= e say something like "Number of=C2=A0 autocommit=C2=A0 transactions...."

My guess is that it doesn=E2=80=99t matter if it=E2=80=99s implici= t or explicit and thus the documentation is correct and adequate.=C2=A0 It = does seem easy enough to prove one way or the other if you think it might b= e incorrect and thus to warrant a change to the docs. =C2=A0 If it does var= y I=E2=80=99d have reason to suspect that a pure select query would exhibit= different behavior than an insert or delete query - i.e., whether a new xi= d is issued makes a difference.

I may experiment m= yself when I=E2=80=99m back at a computer but as you are raising the potent= ial issue the research seems like something that should be done to support = the suggestion.=C2=A0 It isn=E2=80=99t like this will require source code r= eading to discern.

David J.

--000000000000be3aab05e085ab15--