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
meto read and understand these?<br /><br />I'm guessing though that a delete from and then an insert never requires an
exclusivelock, what about adding/deleting constraints?<br /><br />Rob<br /><br /><br /><br /><div
class="gmail_quote">2008/11/26Gregory Stark <span dir="ltr"><<a
href="mailto:stark@enterprisedb.com">stark@enterprisedb.com</a>></span><br/><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">Rob
Kirkbride<<a href="mailto:rob.kirkbride@gmail.com">rob.kirkbride@gmail.com</a>> writes:<br /><br /></div><div
class="Ih2E3d">>Richard,<br /> ><br /> > Yes, I've changed it use TRUNCATE rather than DELETE and it's working
wellfor<br /> > us now.<br /><br /></div>I'm a bit surprised actually as it sounded like you were aiming to avoid
the<br/> table lock. A TRUNCATE does require an exclusive lock on the table. It still<br /> has advantages over DROP in
thatthere is no window when the table does not<br /> exist and any existing references to the table from views or
functionswill<br /> continue to function.<br /><br /><br /> --<br /><div class="Ih2E3d"> Gregory Stark<br />
EnterpriseDB <a href="http://www.enterprisedb.com" target="_blank">http://www.enterprisedb.com</a><br /></div>
Askme about EnterpriseDB's RemoteDBA services!<br /></blockquote></div><br />