JanWieck@t-online.de (Jan Wieck) writes:
>>>> OTOH I don't think it's a good thing to try creating
>>>> these things on the fly the first time needed. The
>>>> required catalog changes and file creations introduce all
>>>> kinds of possible rollback/crash problems, that we don't
>>>> want to have here - do we?
AFAIK we are pretty solid on rolling back table creation, it's just
rename/drop that have problems. A worse problem is what if two
backends both decide they need to create the toast table at the same
time. That might be fixable with appropriate locking but it seems
like there'd be potential for deadlocks.
> Bruce Momjian wrote:
>> Well, we could print the message suggesing ALTER TABLE when printing
>> tuple too large. Frankly, I don't see a problem in creating the backup
>> table automatically. If you are worried about performance, how about
>> putting it in a subdirectory.
I agree with Bruce --- the toast table should be created automatically,
at least if the table contains any potentially-toastable columns. We
want this to be as transparent as possible. I'd rather have auto create
on-the-fly when first needed, but if that seems too risky then let's
just make the table when its owning table is created.
If you want to control it with an ALTER TABLE function, let's add ALTER
TABLE DROP TOAST so that admins who don't like the excess space usage
can get rid of it. (Of course that should only succeed after verifying
the toast table is empty...)
regards, tom lane
