Gregory Stark wrote:
There is documentation
http://www.postgresql.org/docs/8.3/static/explicit-locking.html
However I found it very confusing when I was first learning. It's not really
the documentation's fault either, there are just a lot of different lock
levels with a lot of different combin
"Rob Kirkbride" <[EMAIL PROTECTED]> writes:
> I must admit I've not read up on the various locks that are set so that's a
> good point. Is there a good reference for me to read and understand these?
>
> I'm guessing though that a delete from and then an insert never requires an
> exclusive lock, w
I must admit I've not read up on the various locks that are set so that's a
good point. Is there a good reference for me to read and understand these?
I'm guessing though that a delete from and then an insert never requires an
exclusive lock, what about adding/deleting constraints?
Rob
2008/11
Rob Kirkbride <[EMAIL PROTECTED]> writes:
> Richard,
>
> Yes, I've changed it use TRUNCATE rather than DELETE and it's working well for
> us now.
I'm a bit surprised actually as it sounded like you were aiming to avoid the
table lock. A TRUNCATE does require an exclusive lock on the table. It sti
Richard,
Yes, I've changed it use TRUNCATE rather than DELETE and it's working
well for us now.
The switching of the database is a good idea - thanks. Unfortunately,
we've not got enough disk space currently to do that, but if we get
problems in the future that will definitely be something w
Rob Kirkbride wrote:
> I've introduced a --delete-not-drop option which simply does a DELETE FROM %
> rather than 'DROP and then CREATE'.
Beware foreign-keys slowing you - TRUNCATE all relevant tables should be
the fastest method if possible.
> I hope this sounds sensible and I haven't missed som
OK thanks for the advice.
What I'm trying to overcome is where we've got a long report running and the
process that is taking data from the main database cannot complete because
of the drop table. I believe a DELETE (and possibly TRUNCATE?) doesn't need
an exclusive lock on the table and therefore
"Rob Kirkbride" <[EMAIL PROTECTED]> writes:
> Once I'm happy with it (I'm a bit rusty at C!), do I post the patch here?
I would say you should post *before* you have a patch you're happy with. As
soon as you have a specific plan of what you want to do it's best to post an
outline of it. That way
Dave,
Ok thanks. Yes, we've got over 1/2 billion rows in one of our tables which
is interesting!
Will post back soon.
Rob
2008/11/25 Dave Page <[EMAIL PROTECTED]>
> On Tue, Nov 25, 2008 at 8:39 PM, Rob Kirkbride <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >
> > I'm very new to hacking postgresql bu
On Tue, Nov 25, 2008 at 8:39 PM, Rob Kirkbride <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm very new to hacking postgresql but am using on a very big site
> (http://ojp.nationalrail.co.uk). One of the issues that we have is moving
> data from a live database to a reports one. I've hacked an extra optio
Hi,
I'm very new to hacking postgresql but am using on a very big site (
http://ojp.nationalrail.co.uk). One of the issues that we have is moving
data from a live database to a reports one. I've hacked an extra option to
pg_dump to delete from tables rather than dropping them.
Once I'm happy with
> On N, 2005-10-13 at 15:13 -0400, Merlin Moncure wrote:
> > I have a situation where I need to hack pg_dump not to dump columns
with
> > a particular name. If this is of interest to the community I can
spend
> > a little extra effort and work up a patch. I'd be curious to see if
> > anyone else
On N, 2005-10-13 at 15:13 -0400, Merlin Moncure wrote:
> I have a situation where I need to hack pg_dump not to dump columns with
> a particular name. If this is of interest to the community I can spend
> a little extra effort and work up a patch. I'd be curious to see if
> anyone else thinks thi
Christopher wrote:
> A general ability to be able to dump views as if they were tables
would
> be more broadly applicable methinks?
>
> Merlin Moncure wrote:
> > I have a situation where I need to hack pg_dump not to dump columns
with
> > a particular name. If this is of interest to the community
A general ability to be able to dump views as if they were tables would
be more broadly applicable methinks?
Merlin Moncure wrote:
I have a situation where I need to hack pg_dump not to dump columns with
a particular name. If this is of interest to the community I can spend
a little extra effo
I have a situation where I need to hack pg_dump not to dump columns with
a particular name. If this is of interest to the community I can spend
a little extra effort and work up a patch. I'd be curious to see if
anyone else thinks this is worthwhile.
Why would I want to do this? I use a global
16 matches
Mail list logo
