I wrote:
> You could have encountered it anytime since TOAST was invented, or at
> least since RETURN QUERY was invented (the latter is newer IIRC).
> The fact that the bug has been there so long and has only been reported
> a couple of times is the main reason why I'm loath to take a brute
> force duplicate-the-data approach to fixing it. Such a fix would
> penalize many more people than it would help.
Just thinking idly about what a not-so-brute-force fix might look like
... I wonder if we could postpone the actual drop of toast tables to
end of transaction? I'm not sure how messy that would be, or if it
would have negative consequences elsewhere. But it might be an idea.
We already postpone removal of the underlying disk files till end
of transaction, since we don't know if a DROP TABLE will get rolled
back. The idea here would be to postpone deletion of the system
catalog entries for the toast table as well.
I'm not likely to work on this idea myself in the near future,
but if anyone else is feeling motivated to attack the problem,
have at it ...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
