From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Pg_upgrade and toast tables bug discovered |
Date: | 2014-07-10 14:46:30 |
Message-ID: | CA+TgmoaYhD8KNfwB_ZgHy7aBQ=YtxBLboJDWwHJmV7sNKimrKA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 9, 2014 at 12:09 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> To me, that sounds vastly more complicated and error-prone than
>> forcing the TOAST tables to be added in a second pass as Andres
>> suggested.
>>
>> But I just work here.
>
> Agreed. I am now thinking we could harness the code that already exists
> to optionally add a TOAST table as part of ALTER TABLE ADD COLUMN. We
> would just need an entry point to call it from pg_upgrade, either via an
> SQL command that checks (and hopefully doesn't do anything else), or a C
> function that does it, e.g. VACUUM would be trivial to run on every
> database, but I don't think it tests that; is _could_ in binary_upgrade
> mode. However, the idea of having a C function plug into the guts of
> the server and call internal functions makes me uncomforable.
Well, pg_upgrade_support's charter is basically to provide access to
the guts of the server in ways we wouldn't normally allow; all that
next-OID stuff is basically exactly that. So I don't think this is
such a big deal. It needs to be properly commented, of course.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-07-10 15:06:49 | Re: LEFT JOINs not optimized away when not needed |
Previous Message | Tom Lane | 2014-07-10 14:37:06 | Re: IMPORT FOREIGN SCHEMA statement |