From: | Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Joel Jacobson <joel(at)gluefinance(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_stat_transaction patch |
Date: | 2010-05-25 08:32:20 |
Message-ID: | 20100525173220.CF6E.52131E4D@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joel Jacobson <joel(at)gluefinance(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan Leto | 2010-05-25 08:34:12 | [PATCH] Add _PG_init to PL language handler documentation |
Previous Message | Hector Beyers | 2010-05-25 07:58:00 | Re: Hiding data in postgresql |