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
