On 1/2/14, 1:32 PM, Tom Lane wrote:
> Heikki Linnakangas <hlinnakangas@vmware.com> writes:
>> The simplest fix would be to just detoast everything on assignment but
>> that was rejected on performance grounds in that previous thread. I
>> don't see any other realistic way to fix this, however, so maybe we
>> should just bite the bullet and do it anyway.
>
> Or just say "don't do that". TRUNCATE on a table that's in use by open
> transactions has all sorts of issues besides this one. The given example
> is a pretty narrow corner case anyway --- with a less contorted coding
> pattern, we'd still have AccessShareLock on the table, blocking the
> TRUNCATE from removing data. I'd still not want to blow up performance
> in order to make this example work.
If concurrent TRUNCATE isn't safe outside of this case then why do we allow it? IE: why doesn't TRUNCATE exclusive lock
therelation?
I'd much rather have working concurrent truncation than having to lock the relation, but if it's not safe we shouldn't
handpeople that footgun...
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net