Re: ERROR: missing chunk number 0 for toast value

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