As far as EXCLUSIVE or COPY LOCK goes, I think this would be useful functionality but perhaps there doesn't have to be any proprietary user interface to it at all. Why not just check if the conditions are already present to allow the optimization and if so go ahead.
That is, if the current transaction already has an exclusive lock on the table and there are no indexes (and PITR isn't active) then Postgres could go ahead and use the same WAL skipping logic as the other operations that already so so. This would work for inserts whether coming from COPY or plain SQL INSERTs. The nice thing about this is that the user's SQL wouldn't need any proprietary extensions at all. Just tell people to do BEGIN; LOCK TABLE foo; COPY foo from ... COMMIT; There could be a COPY LOCK option to obtain a lock, but it would be purely for user convenience so they don't have to bother with BEGIN and COMMIt. The only downside is a check to see if an exclusive table lock is present on every copy and insert. That might be significant but perhaps there are ways to finess that. If not perhaps only doing it on COPY would be a good compromise. -- greg ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly