Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I've spent some time thinking about possible workarounds for this, and
> >> not really come up with any. The only feasible thing I can think of
> >> to do is teach pg_migrator to refuse to migrate if (a) the old DB
> >> contains con
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > For longterm strategy, let me list the challenges for pg_migrator from
> > any major upgrade (listed in the DEVELOPERS file):
> >
> > Change Conversion Method
> >
> >
Bruce Momjian writes:
> Tom Lane wrote:
>> I've spent some time thinking about possible workarounds for this, and
>> not really come up with any. The only feasible thing I can think of
>> to do is teach pg_migrator to refuse to migrate if (a) the old DB
>> contains contrib/isn, and (b) the new DB
Bruce Momjian escribió:
> For longterm strategy, let me list the challenges for pg_migrator from
> any major upgrade (listed in the DEVELOPERS file):
>
> Change Conversion Method
>
> --
Tom Lane wrote:
> I wrote:
> > [ concerning various migration hazards in contrib/ ]
>
> > * isn has got the nastiest problems of the lot: since it piggybacks
> > on type bigint, a migrated database might work, or might crash
> > miserably, depending on whether bigint has become pass-by-value
> > i
Robert Haas writes:
> On Mon, Jun 8, 2009 at 1:32 PM, Tom Lane wrote:
>> You mean like PG_MODULE_MAGIC?
> Hey, how about that. Why doesn't that solve our problem here?
> [ thinks ... ] I guess it's because there's no guarantee that the
> function is installed on the SQL level with the signature
I wrote:
> [ concerning various migration hazards in contrib/ ]
> * isn has got the nastiest problems of the lot: since it piggybacks
> on type bigint, a migrated database might work, or might crash
> miserably, depending on whether bigint has become pass-by-value
> in the new database. I'm not v
Robert Haas wrote:
> > Now, we don't want to over-promise, but at the same time we shouldn't
> > downplay the tool either. ?For a sufficiently-experienced administrator,
> > pg_migrator is a useful migration tool, and we need to convey that.
> > Even if you have to hire a consultant to manage the m
Robert Haas wrote:
> On Mon, Jun 8, 2009 at 1:06 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >> > At a minimum it would be great if items could mark themselves as
> >> > non-binary-upgradable.
> >>
> >> It's hardly difficult to make that happen --- just change the C n
On Mon, Jun 8, 2009 at 1:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> Obviously we don't want to get into connecting to a web site, but we
>> could probably come up with some other API for .so files to indicate
>> which versions of PG they're compatible with.
>
> You mean like PG_MODULE_MAGIC?
Robert Haas writes:
> Obviously we don't want to get into connecting to a web site, but we
> could probably come up with some other API for .so files to indicate
> which versions of PG they're compatible with.
You mean like PG_MODULE_MAGIC?
regards, tom lane
--
Sent via
On Mon, Jun 8, 2009 at 1:20 PM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> > Oh, to me "experimental" does not imply that usefulness is uncertain;
>> > rather, it implies that usefulness has been established but that the
>> > code is new (item #4 above) and may be not be 100% feature-complete
>
On Mon, Jun 8, 2009 at 1:06 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > At a minimum it would be great if items could mark themselves as
>> > non-binary-upgradable.
>>
>> It's hardly difficult to make that happen --- just change the C name of
>> some function, or the n
Bruce Momjian wrote:
> > Oh, to me "experimental" does not imply that usefulness is uncertain;
> > rather, it implies that usefulness has been established but that the
> > code is new (item #4 above) and may be not be 100% feature-complete
> > (items #1 and #3 above).
> >
> > > I think we can say:
Tom Lane wrote:
> Bruce Momjian writes:
> > At a minimum it would be great if items could mark themselves as
> > non-binary-upgradable.
>
> It's hardly difficult to make that happen --- just change the C name of
> some function, or the name of the whole .so file.
Yes, but it needs to happen. ;-
Robert Haas wrote:
> > Let me list the problems with pg_migrator:
> >
> > ? ? ? ?o ?/contrib and plugin migration (not unique to pg_migrator)
> > ? ? ? ?o ?you must read/follow the install instructions
> > ? ? ? ?o ?might require post-migration table/index rebuilds
> > ? ? ? ?o ?new so serious bugs
Bruce Momjian writes:
> At a minimum it would be great if items could mark themselves as
> non-binary-upgradable.
It's hardly difficult to make that happen --- just change the C name of
some function, or the name of the whole .so file.
regards, tom lane
--
Sent via pgsq
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> There is a different problem though: sometimes the recommended fix for
> >> contrib-module incompatibilities is to load the new contrib module into
> >> the target database before trying to load your old dump file. (We told
> >> peo
On Mon, Jun 8, 2009 at 11:08 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > Right now nothing in the project is referring to pg_migrator except in
>> > the press release, and it is marked as beta there. ?How do you want to
>> > deemphasize it more than that? ?Why did I bother working on this if
Bruce Momjian writes:
> Tom Lane wrote:
>> There is a different problem though: sometimes the recommended fix for
>> contrib-module incompatibilities is to load the new contrib module into
>> the target database before trying to load your old dump file. (We told
>> people to do that for 8.2->8.3
Dimitri Fontaine wrote:
> Tom Lane writes:
> > Exactly. And note that this is not pg_migrator's fault: a pg_dump
> > dump and reload of the database exposes the user to the same risks,
> > if the module author has not been careful about compatibility.
>
> It seems to me the dump will contain tex
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I think that #1 and #4 could be substantially alleviated if the
> >> instructions recommended doing a trial run with a schema-only dump
> >> of the database. That is,
> >>
> >> * pg_dumpall -s
> >> * load that into a test installat
Tom Lane wrote:
> Bruce Momjian writes:
> > Dimitri Fontaine wrote:
> >> So the case where pg_migrator still fails is when the .sql file of the
> >> module has changed in a way that restoring what pg_dump gives no longer
> >> match what the .so exposes, or if the new .so is non backward
> >> compa
I wrote:
> * pg_buffercache has changed the view pg_buffercache, which is
> definitely going to be a migration issue. Need to test whether
> it represents a crash risk if the old definition is migrated.
I checked this, and there is not a crash risk: the function successfully
creates its result tu
Tom Lane writes:
> Exactly. And note that this is not pg_migrator's fault: a pg_dump
> dump and reload of the database exposes the user to the same risks,
> if the module author has not been careful about compatibility.
It seems to me the dump will contain text string representation of data
and
Bruce Momjian writes:
> Tom Lane wrote:
>> I think that #1 and #4 could be substantially alleviated if the
>> instructions recommended doing a trial run with a schema-only dump
>> of the database. That is,
>>
>> * pg_dumpall -s
>> * load that into a test installation (of the *old* PG version)
>>
Bruce Momjian writes:
> Dimitri Fontaine wrote:
>> So the case where pg_migrator still fails is when the .sql file of the
>> module has changed in a way that restoring what pg_dump gives no longer
>> match what the .so exposes, or if the new .so is non backward
>> compatible?
> Yes, that is a pro
Tom Lane wrote:
> Dimitri Fontaine writes:
> > So the case where pg_migrator still fails is when the .sql file of the
> > module has changed in a way that restoring what pg_dump gives no longer
> > match what the .so exposes, or if the new .so is non backward
> > compatible?
>
> Exactly. And not
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> There was just some discussion about that on postgis-devel. I think the
> >> conclusion was that you would have to do the PostGIS update as a
> >> separate step. They intend to support both 1.3.x and 1.4.x on current
> >> versions
Tom Lane wrote:
> Bruce Momjian writes:
> > Let me list the problems with pg_migrator:
>
> > o /contrib and plugin migration (not unique to pg_migrator)
> > o you must read/follow the install instructions
> > o might require post-migration table/index rebuilds
> > o new so ser
Dimitri Fontaine writes:
> So the case where pg_migrator still fails is when the .sql file of the
> module has changed in a way that restoring what pg_dump gives no longer
> match what the .so exposes, or if the new .so is non backward
> compatible?
Exactly. And note that this is not pg_migrator
Bruce Momjian writes:
> Tom Lane wrote:
>> There was just some discussion about that on postgis-devel. I think the
>> conclusion was that you would have to do the PostGIS update as a
>> separate step. They intend to support both 1.3.x and 1.4.x on current
>> versions of Postgres for some time, s
Dimitri Fontaine wrote:
> Tom Lane writes:
>
> > Dimitri Fontaine writes:
> >> My vote would go to detect and error out without recovering option. If
> >> the tool is not able to handle a situation and knows it, I don't see
> >> what would be good about it leting the user lose data on purpose.
>
Bruce Momjian writes:
> Let me list the problems with pg_migrator:
> o /contrib and plugin migration (not unique to pg_migrator)
> o you must read/follow the install instructions
> o might require post-migration table/index rebuilds
> o new so serious bugs might exist
Dimitri Fontaine wrote:
> >> I don't think that anything in that line is going to be helpful.
> >> What it will lead to is people mindlessly using --force (cf our
> >> bad experiences with -i for pg_dump). If you can't give a *useful*
> >> ie trustworthy warning/error, issuing a useless one is not
Tom Lane writes:
> Dimitri Fontaine writes:
>> My vote would go to detect and error out without recovering option. If
>> the tool is not able to handle a situation and knows it, I don't see
>> what would be good about it leting the user lose data on purpose.
>
> No, that's not what's being discu
Magnus Hagander wrote:
> Dimitri Fontaine wrote:
> > Le 6 juin 09 ? 20:45, Josh Berkus a ?crit :
> >> So, here's what we need for 8.3 --> 8.4 for contrib modules:
> >
> > That does nothing for external modules whose code isn't in PostgreSQL
> > control. I'm thinking of those examples I cited up-th
Magnus Hagander wrote:
> >>> Could pg_migrator detect usage of "objects" oids (data types in
> >>> relation, index opclass, ...) that are unknown to be in the standard
> >>> -core + contrib distribution, and quit trying to upgrade the cluster in
> >>> this case, telling the user his database is not
Tom Lane wrote:
> Magnus Hagander writes:
> > As long as PostGIS is the same version in both of them, is pg_migrator
> > is likely to work? (one can always run the PostGIS upgrade as a separate
> > step)
>
> There was just some discussion about that on postgis-devel. I think the
> conclusion was
Robert Haas wrote:
> > Right now nothing in the project is referring to pg_migrator except in
> > the press release, and it is marked as beta there. ?How do you want to
> > deemphasize it more than that? ?Why did I bother working on this if the
> > community reaction is to try to figure out how to
Dimitri Fontaine writes:
> My vote would go to detect and error out without recovering option. If
> the tool is not able to handle a situation and knows it, I don't see
> what would be good about it leting the user lose data on purpose.
No, that's not what's being discussed. The proposal is to h
Magnus Hagander writes:
> Tom Lane wrote:
>> Magnus Hagander writes:
Could pg_migrator detect usage of "objects" oids (data types in
relation, index opclass, ...) that are unknown to be in the standard
-core + contrib distribution, and quit trying to upgrade the cluster in
thi
Tom Lane wrote:
> Magnus Hagander writes:
>> As long as PostGIS is the same version in both of them, is pg_migrator
>> is likely to work? (one can always run the PostGIS upgrade as a separate
>> step)
>
> There was just some discussion about that on postgis-devel. I think the
> conclusion was th
Magnus Hagander writes:
> As long as PostGIS is the same version in both of them, is pg_migrator
> is likely to work? (one can always run the PostGIS upgrade as a separate
> step)
There was just some discussion about that on postgis-devel. I think the
conclusion was that you would have to do the
On Sun, Jun 7, 2009 at 12:36 PM, Tom Lane wrote:
> I wrote:
>> * pageinspect has changed the ABI of get_raw_page() in a way that will
>> likely make it dump core if the function definition is migrated from
>> an old DB. This needs to be fixed.
>> [ and similarly for some other contrib modules ]
>
Dimitri Fontaine wrote:
> Le 6 juin 09 à 20:45, Josh Berkus a écrit :
>> So, here's what we need for 8.3 --> 8.4 for contrib modules:
>
> That does nothing for external modules whose code isn't in PostgreSQL
> control. I'm thinking of those examples I cited up-thread --- and some
> more. (ip4r, te
Robert Haas wrote:
On Sun, Jun 7, 2009 at 11:50 PM, Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
Josh Berkus wrote:
On 6/7/09 10:56 AM, Robert Haas wrote:
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 fe
On Sun, Jun 7, 2009 at 11:50 PM, Bruce Momjian wrote:
> Stefan Kaltenbrunner wrote:
>> Josh Berkus wrote:
>> > On 6/7/09 10:56 AM, Robert Haas wrote:
>> >> 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 featu
Tom Lane wrote:
> Robert Haas 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.
Stefan Kaltenbrunner wrote:
> Josh Berkus wrote:
> > On 6/7/09 10:56 AM, Robert Haas wrote:
> >> 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.
> >
>
Robert Haas wrote:
> 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 CVE
Tom Lane wrote:
> The underlying C-level get_raw_page function is still there, but
> it now expects three arguments not two, and will crash if it's
> passed an int4 where it's expecting a text argument. But the old
> function definition will migrate without error --- there's no way
> for pg_migrat
Tom Lane wrote:
> Bruce Momjian writes:
> > I think the cleanest solution is to document that these issues might
> > happen and suggest solutions.
>
> No, the cleanest solution is to fix it before people ever see a
> problem. This is trivial to do in the case of dblink and I don't
> see why you
Josh Berkus wrote:
On 6/7/09 10:56 AM, Robert Haas wrote:
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.
Yes, I'm calling it "pg_migrator beta" in any advo
On 6/7/09 10:56 AM, Robert Haas wrote:
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.
Yes, I'm calling it "pg_migrator beta" in any advocacy/PR about it.
A
On Jun 7, 2009, at 12:03 PM, Tom Lane wrote:
Robert Haas 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 F
Grzegorz Jaskiewicz wrote:
>
> On 7 Jun 2009, at 03:27, Bruce Momjian wrote:
>
> > Grzegorz Jaskiewicz wrote:
> >>
> >> On 6 Jun 2009, at 19:50, Tom Lane wrote:
> >>> We have five days.
> >>>
> >>> I don't think we need testing, per se. The first step should be to
> >>> diff
> >>> the 8.3 and 8.
I wrote:
> * pageinspect has changed the ABI of get_raw_page() in a way that will
> likely make it dump core if the function definition is migrated from
> an old DB. This needs to be fixed.
> [ and similarly for some other contrib modules ]
After thinking about this some more, I think that there
Robert Haas 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 c
Tom Lane wrote:
Robert Haas writes:
I think it's becoming increasingly clear that pg_migrator is not for
the faint of heart; in fact, I think we should hedge references to it
with words like "experimental".
Probably ...
I'm with Robert on that one - while pg_migrator is extremely inmportant
On Jun 7, 2009, at 10:04 AM, Tom Lane wrote:
Robert Haas writes:
I think it's becoming increasingly clear that pg_migrator is not for
the faint of heart; in fact, I think we should hedge references to it
with words like "experimental".
Probably ...
Just to recall the history, the first pg
Robert Haas writes:
> I think it's becoming increasingly clear that pg_migrator is not for
> the faint of heart; in fact, I think we should hedge references to it
> with words like "experimental".
Probably ...
> Just to recall the history, the first pgfoundry
> commit messages for this tool were
On Sun, Jun 7, 2009 at 12:11 AM, Tom Lane wrote:
> * intarray has removed its internal @> and <@ operators. As I was
> mentioning the other day, it might be the best thing to just revert
> that change anyway, until we can get a better handle on the behavior
> of GIN for empty arrays.
+1.
> So we
On 7 Jun 2009, at 03:27, Bruce Momjian wrote:
Grzegorz Jaskiewicz wrote:
On 6 Jun 2009, at 19:50, Tom Lane wrote:
We have five days.
I don't think we need testing, per se. The first step should be to
diff
the 8.3 and 8.4 versions of the various contrib .sql.in files and
determine what chan
Bruce Momjian writes:
> I think the cleanest solution is to document that these issues might
> happen and suggest solutions.
No, the cleanest solution is to fix it before people ever see a
problem. This is trivial to do in the case of dblink and I don't
see why you think it would be better to ma
Josh Berkus wrote:
> On 6/5/09 6:27 PM, Bruce Momjian wrote:
> > Josh Berkus wrote:
> >> Bruce,
> >>
> >> Assuming a contrib module *hasn't* changed its API, does pg_migrator
> >> link against the 8.4 version of the module's .so, or the old 8.3 version?
> >
> > 8.4 version, or whatever is in the 8.
Tom Lane wrote:
> Josh Berkus writes:
> > So, here's what we need for 8.3 --> 8.4 for contrib modules:
>
> > 1) make a list of contrib modules which do not convert cleanly (testers?)
> > 2) document these.
> > 3) give pg_migrator some hackish way to install 8.4 contrib modules from
> > source be
Grzegorz Jaskiewicz wrote:
>
> On 6 Jun 2009, at 19:50, Tom Lane wrote:
> > We have five days.
> >
> > I don't think we need testing, per se. The first step should be to
> > diff
> > the 8.3 and 8.4 versions of the various contrib .sql.in files and
> > determine what changed. Any module whose
Dimitri Fontaine wrote:
> Le 6 juin 09 ? 20:45, Josh Berkus a ?crit :
> > So, here's what we need for 8.3 --> 8.4 for contrib modules:
>
> That does nothing for external modules whose code isn't in PostgreSQL
> control. I'm thinking of those examples I cited up-thread --- and some
> more. (ip4
Le 6 juin 09 à 20:45, Josh Berkus a écrit :
So, here's what we need for 8.3 --> 8.4 for contrib modules:
That does nothing for external modules whose code isn't in PostgreSQL
control. I'm thinking of those examples I cited up-thread --- and some
more. (ip4r, temporal, prefix, hstore-new, or
On 6 Jun 2009, at 19:50, Tom Lane wrote:
We have five days.
I don't think we need testing, per se. The first step should be to
diff
the 8.3 and 8.4 versions of the various contrib .sql.in files and
determine what changed. Any module whose .sql.in file hasn't changed
is definitely safe.
I
Josh Berkus writes:
> So, here's what we need for 8.3 --> 8.4 for contrib modules:
> 1) make a list of contrib modules which do not convert cleanly (testers?)
> 2) document these.
> 3) give pg_migrator some hackish way to install 8.4 contrib modules from
> source before copying over the database
On 6/5/09 6:27 PM, Bruce Momjian wrote:
Josh Berkus wrote:
Bruce,
Assuming a contrib module *hasn't* changed its API, does pg_migrator
link against the 8.4 version of the module's .so, or the old 8.3 version?
8.4 version, or whatever is in the 8.4 lib, which should be 8.4.
So, here's what w
Dimitri Fontaine wrote:
> Hi,
>
> Ah, we need module/extension/package/plugin so badly...
>
> Le 5 juin 09 ? 22:19, Bruce Momjian a ?crit :
> > I am afraid /contrib is going to be a mine field for this type of
> > problem so I am going to recommend uninstaling the /contrib module if
> > possible
Josh Berkus wrote:
> Bruce,
>
> Assuming a contrib module *hasn't* changed its API, does pg_migrator
> link against the 8.4 version of the module's .so, or the old 8.3 version?
8.4 version, or whatever is in the 8.4 lib, which should be 8.4.
--
Bruce Momjian http://momjian.us
Ente
On Fri, Jun 5, 2009 at 6:11 PM, Dimitri Fontaine wrote:
> Some example modules that I can think of and are wildspread in the field, as
> far as I know, are ip4r (data type and indexes), orafce (functions, views,
> tables), and some less spread are prefix (data type and indexes) or temporal
> (peri
Bruce,
Assuming a contrib module *hasn't* changed its API, does pg_migrator
link against the 8.4 version of the module's .so, or the old 8.3 version?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Hi,
Ah, we need module/extension/package/plugin so badly...
Le 5 juin 09 à 22:19, Bruce Momjian a écrit :
I am afraid /contrib is going to be a mine field for this type of
problem so I am going to recommend uninstaling the /contrib module if
possible and retry the migration. That should work i
Tom Lane wrote:
> Bruce Momjian writes:
> > Brad Nicholson wrote:
> >> At the very least, a mention in the documentation of incompatible
> >> contrib module(s) would be nice. Even better would be a sanity check
> >> added to prevent this.
>
> > OK, I am looking to the hackers group for recomment
Bruce Momjian wrote:
> > There is no nice answer to this. It goes way beyond data types: you
> > could be using the module stuff in indexes, functions, views etc. You
> > can't just drop the stuff. The best I have been able to do in similar
> > cases is to install the updated module in the datab
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> >> At the very least, a mention in the documentation of incompatible
> >> contrib module(s) would be nice. Even better would be a sanity check
> >> added to prevent this.
> >>
> >
> > OK, I am looking to the hackers group for recommentation
Brad Nicholson wrote:
> > When you say "corrupted", I assume you mean you have remove the _old
> > suffixes to restart your 8.3 instance, right? I hope that is the only
> > corruption issue --- please confirm.
>
> Unfortunately no - when I try and start the old version, I get:
>
> pg_ctl -D pgsq
Bruce Momjian writes:
> Brad Nicholson wrote:
>> At the very least, a mention in the documentation of incompatible
>> contrib module(s) would be nice. Even better would be a sanity check
>> added to prevent this.
> OK, I am looking to the hackers group for recommentations on this.
One thing I w
On Fri, 2009-06-05 at 15:50 -0400, Bruce Momjian wrote:
> Brad Nicholson wrote:
> > I've been kicking the tires on this a bit, and I've found an issue when
> > dealing with contrib/ (specifically dblink, although I haven't looked
> > around anymore).
> >
> > dblink_current_query() is not in the 8.
Bruce Momjian wrote:
At the very least, a mention in the documentation of incompatible
contrib module(s) would be nice. Even better would be a sanity check
added to prevent this.
OK, I am looking to the hackers group for recommentations on this. I
wonder if I should recommend uninstall
Brad Nicholson wrote:
> I've been kicking the tires on this a bit, and I've found an issue when
> dealing with contrib/ (specifically dblink, although I haven't looked
> around anymore).
>
> dblink_current_query() is not in the 8.4 version - when I run
> pg_migrator on an 8.3 cluster that has dbli
I've been kicking the tires on this a bit, and I've found an issue when
dealing with contrib/ (specifically dblink, although I haven't looked
around anymore).
dblink_current_query() is not in the 8.4 version - when I run
pg_migrator on an 8.3 cluster that has dblink installed, I get the
following:
87 matches
Mail list logo
