On Tue, 2006-02-07 at 18:59 -0600, Jim C. Nasby wrote:
> 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...
All DDL takes locks, on all DBMS.
Best Regards, Si
On Tue, Feb 07, 2006 at 10:09:02PM +, 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 occur
ql.org
> Subject: Re: [PERFORM] partitioning and locking problems
>
> 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
&
At 05:09 PM 2/7/2006, Simon Riggs wrote:
I'd be disinclined to using the locking system as a scheduling tool.
I Agree with Simon. Using the locking system for scheduling feels
like a form of Programming by Side Effect.
Ron
---(end of broadcast)---
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
On Wed, Feb 01, 2006 at 10:20:21AM -0500, Tom Lane wrote:
> "Marc Morin" <[EMAIL PROTECTED]> 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 (a
, 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 v
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
"Marc Morin" <[EMAIL PROTECTED]> 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.
> The upd
m: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 01, 2006 12:50 AM
> To: Marc Morin
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] partitioning and locking problems
>
> "Marc Morin" <[EMAIL PROTECTED]> writes:
> > Would l
Marc Morin wrote:
Under both these circumstances (truncate and create / replace rule) the
locking behaviour of these commands can cause locking problems for us.
The scenario is best illustrated as a series of steps:
1- long running report is running on view
2- continuous inser
"Marc Morin" <[EMAIL PROTECTED]> writes:
> Would like to understand the implications of changing postgres'
> code/locking for rule changes and truncate to not require locking out
> select statements?
It won't work...
regards, tom lane
---(end of
We have a large database system designed around partitioning. Our
application is characterized with
- terabytes of data
- billions of rows in dozens of base tables (and 100s of paritions)
- 24x7 insert load of new data that cannot be stopped, data is time
sensitive.
- periodic reports that can h
13 matches
Mail list logo
