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.
> -----Original Message-----
> From: Markus Schaber [mailto:schabi@logix-tt.com]
> Sent: Thursday, February 02, 2006 7:44 AM
> To: Marc Morin
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] partitioning and locking problems
>
> Hi, Marc,
>
> 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).
>
> Apart from having two separate views (one for report, one for
> insert) as Richard suggested:
>
> If you have fixed times for #3, don't start any #1 that won't
> finish before it's time for #3.
>
> You could also use the LOCK command on an empty lock table at
> the beginning of each #1 or #3 transaction to prevent #3 from
> getting the view lock before #1 is finished.
>
>
> HTH,
> Markus
>
> --
> Markus Schaber | Logical Tracking&Tracing International AG
> Dipl. Inf. | Software Development GIS
>
> Fight against software patents in EU! www.ffii.org
> www.nosoftwarepatents.org
>
>