pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Jim C. Nasby <jnasby@pervasive.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Marc Morin <marc@sandvine.com>
Cc: Markus Schaber <schabi@logix-tt.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: partitioning and locking problems
Date: Tue, 7 Feb 2006 18:59:12 -0600
Message-ID: <20060208005912.GS38134@pervasive.com> (raw)
In-Reply-To: <1139350142.1258.174.camel@localhost.localdomain>
References: <2BCEB9A37A4D354AA276774EE13FB8C2BCC2A6@mailserver.sandvine.com>
	<1139350142.1258.174.camel@localhost.localdomain>

On Tue, Feb 07, 2006 at 10:09:02PM +0000, Simon Riggs wrote:
> 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).

Unfortunately, AFAIK rule changes would suffer from the exact same
problem, which will be a serious issue for table partitioning. If you
try and add a new partition while a long report is running you'll end up
blocking everything.

ALso, IIRC the OP was trying *not* to have the locking system impose
scheduling. I believe the intention is that either 1 not block 3 or 3
not block 4.

I'm honestly somewhat surprised someone hasn't run into this problem
with partitioning yet; or maybe everyone who needs to do long
transactions just shoves those off to slony slaves...
-- 
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



view thread (13+ messages)  latest in thread

Message-ID: <20060208005912.GS38134@pervasive.com>
Permalink:  ../20060208005912.GS38134@pervasive.com/
Also on:    postgresql.org/message-id/20060208005912.GS38134@pervasive.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: jnasby@pervasive.com, simon@2ndquadrant.com, marc@sandvine.com, schabi@logix-tt.com
  Subject: Re: partitioning and locking problems
  In-Reply-To: <20060208005912.GS38134@pervasive.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox