Date: Mon, 6 Feb 2006 22:11:05 -0600
From: "Jim C. Nasby" <jnasby@pervasive.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Marc Morin <marc@sandvine.com>, pgsql-performance@postgresql.org
Subject: Re: partitioning and locking problems
Message-ID: <20060207041105.GY1240@pervasive.com>
References: <2BCEB9A37A4D354AA276774EE13FB8C263B3E5@mailserver.sandvine.com>
	<307.1138807221@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <307.1138807221@sss.pgh.pa.us>
User-Agent: Mutt/1.5.11

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