PFA the required header file.
Regards,
--
Kedar.
On Tue, Jun 9, 2009 at 12:26 AM, Jaime Casanova <
jcasa...@systemguards.com.ec> wrote:
> On Mon, Jun 8, 2009 at 1:38 PM, Grzegorz Jaskiewicz
> wrote:
> >
> > make[3]: *** No rule to make target
> `../../../src/include/catalog/pg_partition.h', nee
On Mon, Jun 8, 2009 at 7:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> I see that you've carefully not quoted Greg's remark about "mechanism
>> not policy" with which I completely agree.
>
> Mechanism should exist to support useful policy. I don't believe that
> the proposed switch has any real
Hi,
I pgdump'ed a 8.3.7 database and loaded the dump to a different server
running PostgreSQL 8.4 beta 2 (compiled from source) under Opensolaris.
One of the tables has about 6 million records, and a Btree index that
spans 3 columns.
I am having the problem that some queries are unable to f
Robert Haas writes:
> I see that you've carefully not quoted Greg's remark about "mechanism
> not policy" with which I completely agree.
Mechanism should exist to support useful policy. I don't believe that
the proposed switch has any real-world usefulness.
regards, tom
On Mon, Jun 8, 2009 at 4:30 PM, Tom Lane wrote:
> Greg Stark writes:
>>> On Mon, 2009-06-08 at 09:47 -0400, Tom Lane wrote:
I think the proposed don't-restart flag is exceedingly ugly and will not
solve any real-world problem.
>
>> Hm. I'm not sure I see a solid use case for it -- in my
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
Greg Stark writes:
>> On Mon, 2009-06-08 at 09:47 -0400, Tom Lane wrote:
>>> I think the proposed don't-restart flag is exceedingly ugly and will not
>>> solve any real-world problem.
> Hm. I'm not sure I see a solid use case for it -- in my experience you
> want to be pretty sure you have a pers
On Mon, Jun 8, 2009 at 6:58 PM, Simon Riggs wrote:
>
> On Mon, 2009-06-08 at 09:47 -0400, Tom Lane wrote:
>
>> I think the proposed don't-restart flag is exceedingly ugly and will not
>> solve any real-world problem.
>
> Agreed.
Hm. I'm not sure I see a solid use case for it -- in my experience yo
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
On Mon, Jun 8, 2009 at 1:38 PM, Grzegorz Jaskiewicz
wrote:
>
> make[3]: *** No rule to make target
> `../../../src/include/catalog/pg_partition.h', needed by `postgres.bki'.
> Stop.
there is no pg_partition.h file in the patch, please send it
--
Atentamente,
Jaime Casanova
Soporte y capacit
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
make -C catalog all
( echo src/backend/catalog/catalog.o src/backend/catalog/dependency.o
src/backend/catalog/heap.o src/backend/catalog/index.o src/backend/
catalog/indexing.o src/backend/catalog/namespace.o src/backend/catalog/
aclchk.o src/backend/catalog/pg_aggregate.o src/backend/catalog/
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?
On Mon, 2009-06-08 at 09:47 -0400, Tom Lane wrote:
> I think the proposed don't-restart flag is exceedingly ugly and will not
> solve any real-world problem.
Agreed.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing li
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
Kedar,
Added to first CommitFest of 8.5. Thanks for the nice test case.
Folks who are not busy with 8.4 are urged to test this as soon as you can.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
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:
On Mon, Jun 8, 2009 at 10:40 AM, Alvaro
Herrera wrote:
> Tom Lane escribió:
>> Alvaro Herrera writes:
>> > Robert Haas escribió:
>> >> Maybe we should just have a GUC to enable/disable
>> >> partial vacuums.
>>
>> > IIRC you can set vacuum_freeze_table_age to 0.
>>
>> That has the same effects as
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
Tom Lane escribió:
> Alvaro Herrera writes:
> > Robert Haas escribi�:
> >> Maybe we should just have a GUC to enable/disable
> >> partial vacuums.
>
> > IIRC you can set vacuum_freeze_table_age to 0.
>
> That has the same effects as issuing VACUUM FREEZE, no?
As far as I can make from the docs,
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
Alvaro Herrera writes:
> Robert Haas escribió:
>> Maybe we should just have a GUC to enable/disable
>> partial vacuums.
> IIRC you can set vacuum_freeze_table_age to 0.
That has the same effects as issuing VACUUM FREEZE, no?
regards, tom lane
--
Sent via pgsql-hackers
Robert Haas escribió:
> Basically, I'm trying to figure out what we're going to recommend to
> someone who gets bitten by whatever remaining corner case still exists
> after your recent patch, and I admit I'm not real clear on what that
> is. VACUUM FULL doesn't seem like a good solution because
Hi,
Quoting "Nicolas Barbier" :
ISTM that back-patching
I take this to mean "back-patching by cherry picking".
a change to a file that wasn't modified on the
back-branch leads exactly to merging a change to a (file-wise)
ancestor?
Regarding the file's contents - and therefore the immediate
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
Gregory Stark writes:
> I think the accepted way to handle this kind of situation is called STONITH --
> "Shoot The Other Node In The Head".
Yeah, and the reason people go to the trouble of having special hardware
for that is that pure-software solutions are unreliable.
I think the proposed don'
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 ]
>
Hi,
On Mon, Jun 8, 2009 at 6:45 PM, Gregory Stark wrote:
> Fujii Masao writes:
>
>> On the other hand, the primary postgres might *not* restart automatically.
>> So, it's difficult for clusterware to choose whether to do failover when it
>> detects the death of the primary postgres, I think.
>
>
Markus Wanner wrote:
Quoting "Mark Mielke" :
I am a theory person - I run things in my head. To me, the concept of
having more context to make the right decision, and an algorithm that
takes advantage of this context to make the right decision, is simple
and compelling on its own. Knowing the
Fujii Masao writes:
> On the other hand, the primary postgres might *not* restart automatically.
> So, it's difficult for clusterware to choose whether to do failover when it
> detects the death of the primary postgres, I think.
I think the accepted way to handle this kind of situation is calle
Hi,
On Fri, Jun 5, 2009 at 9:24 PM, Kolb, Harald (NSN -
DE/Munich) wrote:
>> Good point. I also think that this makes a handling of failover
>> more complicated. In other words, clusterware cannot determine
>> whether to do failover when it detects the death of the primary
>> postgres. A wrong dec
Hi,
Quoting "Nicolas Barbier" :
If I understand correctly, "nearby variable renaming" refers to
changes to the few lines surrounding the changes-to-be-merged.
Hm.. I took that to mean "changes on the same line". I now realize
this interpretation has been an overly strict interpretation.
T
Robert Haas wrote:
> On Fri, Jun 5, 2009 at 12:15 PM, Tom Lane wrote:
>> ... but I'm not at all excited about cluttering the
>> long-term project history with a zillion micro-commits. One of the
>> things I find most annoying about reviewing the current commit history
>> is that Bruce has taken a
Hi,
Quoting "Mark Mielke" :
I am a theory person - I run things in my head. To me, the concept
of having more context to make the right decision, and an algorithm
that takes advantage of this context to make the right decision, is
simple and compelling on its own. Knowing the algorithms tha
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
Hi Sano-san,
On Fri, Jun 5, 2009 at 7:02 PM, Yoshinori Sano wrote:
>> In v8.4, pg_stop_backup waits until all WAL files used during backup
>> are archived.
>> So, "sleep" is already unnecessary for standalone hot backup.
>
> Oh, it's a great news! We don't need to use the unsafe approach (the
> s
72 matches
Mail list logo
