Re: pg_stat_transaction patch

Joel Jacobson <joel@gluefinance.com> wrote:

> I applied all the changes on 9.0beta manually and then it compiled without
> any assertion failures.
> 
> I also changed the oids to a different unused range, since the ones I used
> before had been taken in 9.0beta1.

Thanks, but you still need to test your patch:
- You need to check your patch with "make check", because it requires  adjustments in "rule" test; Your
pg_stat_transaction_functionis the  longest name in the system catalog.
 
- You need to configure postgres with --enable-cassert to enable internal  varidations. The attached test case failed
withthe following TRAP.
 
TRAP: FailedAssertion("!(entry->trans == ((void *)0))", File: "pgstat.c", Line: 715)
TRAP: FailedAssertion("!(tabstat->trans == trans)", File: "pgstat.c", Line: 1758)

> I suspect it is because get_tabstat_entry for some reason returns NULL, in
> for example pg_stat_get_transaction_tuples_inserted(PG_FUNCTION_ARGS).
> 
> Does the function look valid? If you can find the error in it, the other
> functions probably have the same problem.

For the above trap, we can see the comment:   /* Shouldn't have any pending transaction-dependent counts */
We don't expect to read stats entries during transactions. I'm not sure
whether accessing transitional stats during transaction is safe or not.

We might need to go other directions, for example: - Use "session stats" instead "transaction stats". You can see the
same  information in difference of counters between before and after the   transaction. - Export pgBufferUsage instead
ofrelation counters. They are   buffer counters for all relations, but we can obviously export   them because they are
justplain variables.
 

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center