"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> StartTransaction() and CommandCounterIncrement() trigger
> relation cache invalidation. Unfortunately those are insufficient
> to prevent backends from inserting into invalid relations.
>
> If a backend is blocked by vacuum,it would insert into the target
> relation without relation cache invalidation after vacuum.
If that's true, then we have problems far worse than whether mdtruncate
has tried to unlink the segment. What you are saying is that another
backend can attempt to do an insert/update on a relation being vacuumed,
and have gotten as far as deciding which block it's going to insert the
tuple into before it gets blocked by vacuum's AccessExclusiveLock.
If so, that is *broken* and it's not mdtruncate's fault. What happens
if vacuum fills up the chosen block with moved tuples?
I did indeed wonder whether relation cache inval will do the right
thing when another backend is already waiting to access the relation
being invalidated --- but if it does not, we have to fix the inval
mechanism. mdtruncate is the least of our worries.
Vadim, any comments here?
regards, tom lane