On Wed, Feb 01, 2006 at 10:20:21AM -0500, Tom Lane wrote:
> "Marc Morin" <marc@sandvine.com> 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@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
