Subject: Re: partitioning and locking problems
From: Simon Riggs <simon@2ndquadrant.com>
To: Marc Morin <marc@sandvine.com>
Cc: Markus Schaber <schabi@logix-tt.com>,
	pgsql-performance@postgresql.org
In-Reply-To: <2BCEB9A37A4D354AA276774EE13FB8C2BCC2A6@mailserver.sandvine.com>
References: <2BCEB9A37A4D354AA276774EE13FB8C2BCC2A6@mailserver.sandvine.com>
Content-Type: text/plain
Date: Tue, 07 Feb 2006 22:09:02 +0000
Message-Id: <1139350142.1258.174.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Thu, 2006-02-02 at 11:27 -0500, Marc Morin wrote:

> > > 	1- long running report is running on view
> > > 	2- continuous inserters into view into a table via a rule
> > > 	3- truncate or rule change occurs, taking an exclusive lock.
> > > Must wait for #1 to finish.
> > > 	4- new reports and inserters must now wait for #3.
> > > 	5- now everyone is waiting for a single query in #1.   Results
> > > in loss of insert data granularity (important for our application).

> Using a separate lock table is what we've decided to do in this
> particular case to serialize #1 and #3.  Inserters don't take this lock
> and as such will not be stalled. 

Would it not be simpler to have the Inserters change from one table to
another either upon command, on a fixed timing cycle or even better
based upon one of the inserted values (Logdate?) (or all 3?). (Requires
changes in the application layer: 3GL or db functions).

The truncates can wait until the data has stopped being used.

I'd be disinclined to using the locking system as a scheduling tool.

Best Regards, Simon Riggs