Re: Removing pg_migrator limitations

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: Removing pg_migrator limitations
Date: 2009-12-20 18:07:12
Message-ID: 200912201807.nBKI7CR19249@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Tom Lane wrote:
> >> What I had in mind was more like
> >>
> >> static Oid next_pg_class_oid = InvalidOid;
> >>
> >> void
> >> set_next_pg_class_oid(Oid oid)
> >> {
> >> next_pg_class_oid = oid;
> >> }
>
> > Does exporting a function buy us anything vs. exporting a variable?
>
> Hmm, probably not. I generally like to avoid global variables, but
> in this case it doesn't seem to buy us anything to do so. Actually,
> you could just have the core code do
>
> /* don't make this static, pg_migrator needs to set it */
> Oid next_pg_class_oid = InvalidOid;
>
> and not even bother with an extern declaration in the backend header
> files (AFAIK gcc won't complain about that). That would help keep the
> variable private to just the one core module plus pg_migrator.

Yes, that was the idea. We wouldn't expose the variable in other C
files unless necessary.

> > I will work on a patch to accomplish this, and have pg_migrator link in
> > the .so only if the new server is >= 8.5, which allows a single
> > pg_migrator binary to work for migration to 8.4 and 8.5.
>
> I think you're just creating useless work for yourself by imagining that
> pg_migrator is backend-version-independent. In fact, I was thinking
> about proposing that we pull it in as a contrib module. Because so much
> of what it does is tied to details of backend and pg_dump behavior, it's
> just a pipe dream to think that developing it as a separate project is
> helpful.

Well, I do think it will work for 8.3 to 8.4 ,and 8.4 to 8.5 --- I test
that regularly and I have not seen any failures in that regard. If we
move it into /contrib, I will make sure fixes get backpatched. FYI, a
typical test is:

if (GET_MAJOR_VERSION(ctx.old.pg_version) <= 803 &&
GET_MAJOR_VERSION(ctx.new.pg_version) >= 804)

The biggest issue with versions is that it is hard for pg_migrator to
text changes in the server during major development so for example once
we add pg_dump support for system oids, it will then require CVS HEAD
for 8.5, but there are not that many people testing pg_migrator with
non-HEAD versions.

--
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. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-20 18:41:28 LIKE INCLUDING COMMENTS code is a flight of fancy
Previous Message Tom Lane 2009-12-20 17:52:32 Re: Removing pg_migrator limitations