Re: ERROR: missing chunk number 0 for toast value

On 1/2/14, 1:32 PM, Tom Lane wrote:
> Heikki Linnakangas <hlinnakangas(at)vmware(dot)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 the relation?

I'd much rather have working concurrent truncation than having to lock the relation, but if it's not safe we shouldn't hand people that footgun...
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net