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@enterprisedb.com>"Rob Kirkbride" <
rob.kirkbride@gmail.com> writes:
> Once I'm happy with it (I'm a bit rusty at C!), do I post the patch here?
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!
