Thread: txid_current vs xact_commit stats
HI All;
I was under the impression that all transactions must end with a commit or a rollback but watching stats doesn't support this. Web searches tend to return info on what a transaction is or the ratio of commits to rollbacks. I found nothing contradicting what I think I know.
I've sampled pg_stat_database.xact_commit, pg_stat_database.xact_rollback and txid_current() at intervals on a few independent clusters and see that commits increase anywhere from 50% to 300% of the rate of transaction increase. Rollback remains very near zero for all clusters. Each cluster tends to stay consistently within a range (i.e. 120-130% or 50-70%).
I've seen strange issues with the stats collector missing updates and causing problems with autovacuum but that wouldn't explain more commits than transactions. All clusters receive many inserts (~10-100) in single transactions but AFAIK this still counts as a single commit. Many other tables are created while processing the inserted data and much of that is done within transaction blocks. I'm not aware of anything very sophisticated in the application handling this but I could be wrong.
I'm probably missing something fundamental. I know what I know but I'm not a DBA.
PG version 11 & 12 on Linux
Any hints and references appreciated.
Thanks,
Senor
On Wed, 2024-10-09 at 04:22 +0000, senor wrote: > I was under the impression that all transactions must end with a commit or a > rollback but watching stats doesn't support this. Web searches tend to return > info on what a transaction is or the ratio of commits to rollbacks. I found > nothing contradicting what I think I know. The rollback can be implicit, for example when you terminate the connection or crash the server... Also, PostgreSQL has autocommit, so every data modifying statement that's not in an explicit transaction will implicitly commit at the end of the statement. > I've sampled pg_stat_database.xact_commit, pg_stat_database.xact_rollback and > txid_current() at intervals on a few independent clusters and see that commits > increase anywhere from 50% to 300% of the rate of transaction increase. Rollback > remains very near zero for all clusters. Each cluster tends to stay consistently > within a range (i.e. 120-130% or 50-70%). Perhaps what I wrote above explains that. > PG version 11 & 12 on Linux That's too old. Yours, Laurenz Albe
On 10/8/2024 23:39, Laurenz Albe wrote: > On Wed, 2024-10-09 at 04:22 +0000, senor wrote: >> I was under the impression that all transactions must end with a commit or a >> rollback but watching stats doesn't support this. Web searches tend to return >> info on what a transaction is or the ratio of commits to rollbacks. I found >> nothing contradicting what I think I know. > The rollback can be implicit, for example when you terminate the connection or > crash the server... > > Also, PostgreSQL has autocommit, so every data modifying statement that's not > in an explicit transaction will implicitly commit at the end of the statement. This part I'm aware of but I assume whether implicit or explicit it would show up in the stats I'm monitoring. >> I've sampled pg_stat_database.xact_commit, pg_stat_database.xact_rollback and >> txid_current() at intervals on a few independent clusters and see that commits >> increase anywhere from 50% to 300% of the rate of transaction increase. Rollback >> remains very near zero for all clusters. Each cluster tends to stay consistently >> within a range (i.e. 120-130% or 50-70%). > Perhaps what I wrote above explains that. How is it that I'm seeing more commits than transactions? I thought I should see something as simple as commits + rollbacks = transactions. In some cases I'm seeing 3 times as many commits. I'm not aware of multiple commits possible per transaction or commits without a transaction. There doesn't seem to be a problem other than my understanding. >> PG version 11 & 12 on Linux > That's too old. 100% agree. > Yours, > Laurenz Albe Thank you Laurenz for the response. Your replies to my previous posts helped to identify there is an ongoing issue with the stats collection in some clusters. I'm looking forward to an upgrade to PG v16 to manage that. This current question came up while looking into that but I don't think it's involved. Thanks, Senor