Re: pg_migrator issue with contrib

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_migrator issue with contrib
Date: 2009-06-07 17:56:56
Message-ID: 184EC0A7-8312-4ECD-9A88-1553F959FBAB@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jun 7, 2009, at 12:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I did know that EDB had been using the tool for a while, but I admit
>> I'm not familiar with the whole history. I had the impression that
>> we'd gotten a lot more serious about really making this rock solid
>> since Bruce took it in February. But maybe that's not the case?
>
> I don't actually know the EDB end of the history either; maybe someone
> can educate us about that. But it's true that the core developers,
> at least, weren't taking it seriously until this year. That's because
> it really can only handle catalog changes, not changes to the contents
> of user tables; and it's been quite a long time since we've had a
> release where we didn't change tuple header layout or packing rules or
> something that made it a nonstarter. It wasn't clear till early this
> year that 8.3->8.4 would be a cycle where pg_migrator had a chance of
> being useful in production ... so we got serious about it.

OK, that's more or less what I thought, and what I intended to convey
upthread. As far as core Postgres is concerned this is a new feature,
and we haven't worked out all the kinks yet. As long as we set
expectations accordingly, I think that's OK. You mention CVEs for
these contrib issues, but will CVEs still be issued if we make clear
that this is experimental only? I would hope not, since that would
amount to a policy that any half-baked code anywhere on pgfoundry is
just as much our responsibility as core Postgres. Surely we're
allowed to say "good progress has been made here, but we harbor no
illusions that it's bullet-proof."

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-06-07 18:11:58 Re: Partial vacuum versus pg_class.reltuples
Previous Message Joe Conway 2009-06-07 17:34:46 Re: [Fwd: Re: dblink patches for comment]