On 1/2/14, 1:32 PM, Tom Lane wrote:
Heikki Linnakangas <hlinnakan...@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 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 j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
