Re: pg_migrator and handling dropped columns

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
Subject: Re: pg_migrator and handling dropped columns
Date: 2009-02-17 02:28:43
Message-ID: 200902170228.n1H2ShM15396@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote:
> Tom Lane wrote:
> >> Is this acceptable to everyone? We could name the option
> >> -u/--upgrade-compatible.
> >
> > If the switch is specifically for pg_upgrade support (enabling this as
> > well as any other hacks we find necessary), which seems like a good
> > idea, then don't chew up a short option letter for it. There should be
> > a long form only.
>
> Note that pg_dump's output is already upgrade compatible. That's what
> pg_dump is often used for after all. I believe what we are after here
> is something like "in-place upgrade compatible" or "upgrade binary
> compatible".
>
> > And probably not even list it in the user documentation.
>
> I think we should still list it somewhere and say it is for use by
> in-place upgrade utilities. It will only confuse people if it is not
> documented at all.

OK, I have completed the patch; attached.

I ran into a little problem, as documented by this comment in
catalog/heap.c:

/*
* Set the type OID to invalid. A dropped attribute's type link
* cannot be relied on (once the attribute is dropped, the type might
* be too). Fortunately we do not need the type row --- the only
* really essential information is the type's typlen and typalign,
* which are preserved in the attribute's attlen and attalign. We set
* atttypid to zero here as a means of catching code that incorrectly
* expects it to be valid.
*/

Basically, drop column zeros pg_attribute.atttypid, and there doesn't
seem to be enough information left in pg_attribute to guess the typid
that, combined with atttypmod, would restore the proper values for
pg_attribute.atttypid and pg_attribute.attalign. Therefore, I just
brute-forced an UPDATE into dump to set the values properly after
dropping the fake TEXT column.

I did a minimal documentation addition by adding something to the
"Notes" section of the manual pages.

Here is what a dump of a table with dropped columns looks like:

--
-- Name: test; Type: TABLE; Schema: public; Owner: postgres; Tablespace:
--

CREATE TABLE test (
x integer,
"........pg.dropped.2........" TEXT
);
ALTER TABLE ONLY test DROP COLUMN "........pg.dropped.2........";

-- For binary upgrade, recreate dropped column's length and alignment.
UPDATE pg_attribute
SET attlen = -1, attalign = 'i'
WHERE attname = '........pg.dropped.2........'
AND attrelid =
(
SELECT oid
FROM pg_class
WHERE relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = CURRENT_SCHEMA)
AND relname = 'test'
);

ALTER TABLE public.test OWNER TO postgres;

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Attachment Content-Type Size
/pgpatches/pg_dump text/x-diff 11.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2009-02-17 02:30:24 Re: SE-PostgreSQL and row level security
Previous Message KaiGai Kohei 2009-02-17 01:59:02 Re: SE-PostgreSQL and row level security