Joel Jacobson <j...@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_function is the longest name in the system catalog. - You need to configure postgres with --enable-cassert to enable internal varidations. The attached test case failed with the 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 of relation counters. They are buffer counters for all relations, but we can obviously export them because they are just plain variables. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers