On Wed, Feb 01, 2006 at 10:20:21AM -0500, Tom Lane wrote: > "Marc Morin" <marc@xxxxxxxxxxxx> writes: > > Do you mean it would be impossible to change the code so that existing > > selects continue to use the pre-truncated table until they commit? > > Yes, because that table won't exist any more (as in the file's been > unlinked) once the TRUNCATE commits. Is there a reason the truncate must happen in 'real time'? If TRUNCATE marked a table as "truncated as of tid, cid" and created a new set of empty objects to be used by all transactions after that, then it should be possible to truncate without waiting on existing selects. Unfortunately, I can't think of any way to avoid blocking new inserters, but in the partitioning case that shouldn't matter. > > The update/insert rule change appears to be more more doable? No? > > You've still got race conditions there: do onlooker transactions see the > old set of rules, or the new set, or some unholy mixture? Removing the > lock as you suggest would make it possible for the rule rewriter to pick > up non-self-consistent data from the system catalogs, leading to > arbitrarily bad behavior ... if you're lucky, it'll just crash, if > you're not lucky the incorrect rule will do a fandango on your data. Where can one read about why the catalogs can't/don't use MVCC (I'm assuming that's why this won't work...) -- Jim C. Nasby, Sr. Engineering Consultant jnasby@xxxxxxxxxxxxx Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
