Обсуждение: pg_stat_database view column xact_commit description should be more descriptive?
xact_commitbigintNumber of transactions in this database that have been committed
BEGINinitiates a transaction block, that is, all statements after aBEGINcommand will be executed in a single transaction until an explicitCOMMITorROLLBACKis given. By default (withoutBEGIN), PostgreSQL executes transactions in “autocommit” 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...."
I recommend David Deutsch's <<The Beginning of Infinity>>
Jian
Re: pg_stat_database view column xact_commit description should be more descriptive?
От
"David G. Johnston"
Дата:
On Thursday, June 2, 2022, jian he <jian.universality@gmail.com> wrote:
xact_commitbigintNumber of transactions in this database that have been committed
BEGINinitiates a transaction block, that is, all statements after aBEGINcommand will be executed in a single transaction until an explicitCOMMITorROLLBACKis given. By default (withoutBEGIN), PostgreSQL executes transactions in “autocommit” 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’t matter if it’s implicit or explicit 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’d 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’m 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’t like this will require source code reading to discern.
David J.
Sorry.
It refers to all the transactions.
On Fri, Jun 3, 2022 at 12:30 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Thursday, June 2, 2022, jian he <jian.universality@gmail.com> wrote:
xact_commitbigintNumber of transactions in this database that have been committed
BEGINinitiates a transaction block, that is, all statements after aBEGINcommand will be executed in a single transaction until an explicitCOMMITorROLLBACKis given. By default (withoutBEGIN), PostgreSQL executes transactions in “autocommit” 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’t matter if it’s implicit or explicit 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’d 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’m 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’t like this will require source code reading to discern.David J.
--
I recommend David Deutsch's <<The Beginning of Infinity>>
Jian
Re: pg_stat_database view column xact_commit description should be more descriptive?
От
Jaime Casanova
Дата:
On Fri, Jun 3, 2022 at 1:46 AM jian he <jian.universality@gmail.com> 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 BEGIN command will be executed in a single transactionuntil an explicit COMMIT or ROLLBACK is given. By default (without BEGIN), PostgreSQL executes transactions in“autocommit” mode, that is, each statement is executed in its own transaction and a commit is implicitly performed at theend 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...." > Hi, I want to hijack this thread to say that xact_commit seems to be also counting COMMIT records received by logical replication. Should we explain that in documentation? What about physical replication? Are those also counted? -- Jaime Casanova Director de Servicios Profesionales SYSTEMGUARDS S.A.
Re: pg_stat_database view column xact_commit description should be more descriptive?
От
"Euler Taveira"
Дата:
On Fri, Dec 16, 2022, at 5:40 PM, Jaime Casanova wrote:
I want to hijack this thread to say that xact_commit seems to be alsocounting COMMIT records received by logical replication.Should we explain that in documentation?
Probably. I don't think adding something to pg_stat_database is appropriate.
IMO this concept should be explained in the logical replication chapter [1].
Logical replication uses transaction infrastructure to apply changes, hence,
statistics will take it into account.
What about physical replication? Are those also counted?
No. Physical replication does not use the transaction machinery to replicate
changes. It is in a lower layer and statistics don't apply at it.