Alvaro Herrera <alvhe...@commandprompt.com> writes: > Tom Lane wrote: >> Maybe we should do >> something about this. There wasn't any obvious solution before, >> but now that we have the nontransactional smgr-level sinval messages >> being sent on drops and truncates, it seems like tying rd_targblock >> clearing to those would fix the problem.
> Hmm, sounds good, though I confess not having heard about > nontransactional sinval messages before. Hey, they've been in there almost a week ;-) http://archives.postgresql.org/pgsql-committers/2010-02/msg00026.php >> The easiest way to do that >> would involve moving rd_targblock down to the SMgrRelation struct. >> Probably rd_fsm_nblocks and rd_vm_nblocks too. Comments? > Can't say it doesn't look like a modularity violation from here -- > insertion target block doesn't really belong into smgr, does it? It never belonged in relcache, either. Trying to keep dynamic state (not backed by a catalog entry) in the relcache has always been a pretty klugy thing. smgr at least has a reasonable excuse for trying to keep track of physical truncation events, which is the thing we need here. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
