On Tue, 30 May 2000, Tom Lane wrote:
> 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.
have to third this one ... I think it should be totally transparent to the
admin/user ... just create it when the table is created, what's the worst
case scenario? it never gets used and you waste 16k of disk space?
