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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers