Re: Enhancement to pg_dump

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 can continue.

I've introduced a --delete-not-drop option which simply does a DELETE FROM %
rather than 'DROP and then CREATE'.

I hope this sounds sensible and I haven't missed something - I'm still
learning!

Rob

2008/11/25 Gregory Stark <stark(at)enterprisedb(dot)com>

> "Rob Kirkbride" <rob(dot)kirkbride(at)gmail(dot)com> 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 you at least have a chance of avoiding wasting work
> in
> the wrong direction.
>
> Sometimes things don't really work out that way -- sometimes the plan
> sounds
> good and it only becomes apparent there's a better way later -- but you're
> best off getting the best chance you can.
>
> Incidentally, I don't know exactly what the use case you're trying to cover
> here is but you should consider looking at TRUNCATE instead of DELETE if
> you're really deleting all the records in the table and can accept locking
> the
> table.
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> Ask me about EnterpriseDB's Slony Replication support!
>