Re: [PATCHES] pgstat_drop_relation bugfix
Tom Lane [EMAIL PROTECTED] wrote: What I'm inclined to propose is that we just remove the pgstat_drop_relation() call from smgr_internal_unlink On checking the CVS history, that in fact is how the code worked before 8.1.3, when I introduced the bogus call in a fit of over-optimization :-(. I'm worried that we leave garbage entries in the stats. As you suggested, don't we need to remove unreferenced entries from stats periodically? and rely entirely on VACUUM to clean out dead entries in the pgstats data. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] pgstat_drop_relation bugfix
ITAGAKI Takahiro [EMAIL PROTECTED] writes: I'm worried that we leave garbage entries in the stats. As you suggested, don't we need to remove unreferenced entries from stats periodically? VACUUM does that already. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] pgstat_drop_relation bugfix
I wrote: What I'm inclined to propose is that we just remove the pgstat_drop_relation() call from smgr_internal_unlink, and rely entirely on VACUUM to clean out dead entries in the pgstats data. On checking the CVS history, that in fact is how the code worked before 8.1.3, when I introduced the bogus call in a fit of over-optimization :-(. I vaguely recall thinking that the chance of losing data would be small and pgstat is subject to losing data anyway. However, we are definitely moving (slowly) in the direction of making pgstat more trustworthy, so it's probably best not to take the risk of dropping useful stats. Call removed from 8.1.x and up. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PATCHES] pgstat_drop_relation bugfix
I wrote: pgstat_drop_relation() is expecting relid (pg_class.oid) as the argument, but we pass it relfilenode. I'm trying to fix the bug, because there is a possibility that some useless statistics data continue to occupy some parts of the statistics table. Here is a patch to fix undropped entries in the runtime statistics table. Now smgr records the relation oids and uses them to drop entries corresponding the relations. We could make stray entries easily using the following queries. CREATE TABLE test (i integer); INSERT INTO test VALUES(1); TRUNCATE test; DROP TABLE test; Since we don't discard any of stat entries except pg_stat_reset(), those useless entries would cause memory leaks, though it is very trivial. I fell my fix is uncool; Let me know if there are any other better ways. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center pgstat_drop_relation.patch Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
