On Sun, 2006-10-22 at 12:12 -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Simon Riggs wrote: > >> I think it is possible to detect this case without making catalog > >> entries, so I'll give this a try. Methinks that the truncate *must* be > >> the immediately preceding command, otherwise we might have a trigger > >> executing to put rows back into the table before we COPY. > > > Hmm, is it possible to save the "is empty" info somewhere in local > > memory, perhaps the relcache (not necessarily propagated), and have > > heap_insert turn it off? > > The relcache isn't a very safe place to store state --- it's a cache, > not stable storage.
I was imagining adding this onto the Relation struct, just as we do with rd_createSubid and rd_targblock. That isn't a safe place to store that state so we can't do this across multiple backends. We wouldn't want that anyway since otherwise various statements would need to access shared state before they can act, which is not good. > However, I don't understand why Simon is on about "empty". ISTM the > important state is "new relfilenode assigned in this transaction". Thank you for supplying clarity of thought; empty would be important if we were taking full table locks, which we don't want to do (Christmas Past...). So we need not have the DML immediately following a truncate, only that a truncate has previously occurred within the top level transaction or an unaborted subtransaction. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
