On Sun, 2006-10-22 at 12:12 -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> 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