Hi Sano-san,
On Fri, Jun 5, 2009 at 7:02 PM, Yoshinori Sanoyoshinori.s...@gmail.com 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
Robert Haas wrote:
On Sun, Jun 7, 2009 at 11:50 PM, Bruce Momjianbr...@momjian.us 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
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, temporal,
Hi,
Quoting Mark Mielke m...@mark.mielke.cc:
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
Robert Haas wrote:
On Fri, Jun 5, 2009 at 12:15 PM, Tom Lanet...@sss.pgh.pa.us 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
Hi,
Quoting Nicolas Barbier nicolas.barb...@gmail.com:
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
Hi,
On Fri, Jun 5, 2009 at 9:24 PM, Kolb, Harald (NSN -
DE/Munich)harald.k...@nsn.com 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.
Fujii Masao masao.fu...@gmail.com 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
Markus Wanner wrote:
Quoting Mark Mielke m...@mark.mielke.cc:
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
Hi,
On Mon, Jun 8, 2009 at 6:45 PM, Gregory Starkst...@enterprisedb.com wrote:
Fujii Masao masao.fu...@gmail.com 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
On Sun, Jun 7, 2009 at 12:36 PM, Tom Lanet...@sss.pgh.pa.us 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
Gregory Stark st...@enterprisedb.com 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
Magnus Hagander mag...@hagander.net 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
Tom Lane wrote:
Magnus Hagander mag...@hagander.net 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
Hi,
Quoting Nicolas Barbier nicolas.barb...@gmail.com:
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
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
Alvaro Herrera alvhe...@commandprompt.com 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
--
Magnus Hagander mag...@hagander.net writes:
Tom Lane wrote:
Magnus Hagander mag...@hagander.net 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
Dimitri Fontaine dfonta...@hi-media.com 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.
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com 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
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 make
Tom Lane wrote:
Magnus Hagander mag...@hagander.net 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
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 supported?
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-thread --- and
Tom Lane t...@sss.pgh.pa.us writes:
Dimitri Fontaine dfonta...@hi-media.com 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.
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 a good
Bruce Momjian br...@momjian.us 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
Dimitri Fontaine wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Dimitri Fontaine dfonta...@hi-media.com 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
Bruce Momjian br...@momjian.us 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
Dimitri Fontaine dfonta...@hi-media.com 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Dimitri Fontaine dfonta...@hi-media.com 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?
Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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
Tom Lane t...@sss.pgh.pa.us 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
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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Dimitri Fontaine wrote:
Tom Lane t...@sss.pgh.pa.us 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
Bruce Momjian br...@momjian.us 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
On Mon, Jun 8, 2009 at 11:08 AM, Bruce Momjianbr...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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
--
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 might
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
On Mon, Jun 8, 2009 at 10:40 AM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com 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.
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: ?pg_migrator
On Mon, Jun 8, 2009 at 1:06 PM, Bruce Momjianbr...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
On Mon, Jun 8, 2009 at 1:20 PM, Bruce Momjianbr...@momjian.us 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%
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
Robert Haas robertmh...@gmail.com 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
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
On Mon, Jun 8, 2009 at 1:32 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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.
Robert Haas wrote:
On Mon, Jun 8, 2009 at 1:06 PM, Bruce Momjianbr...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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
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
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 very
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 8, 2009 at 1:32 PM, Tom Lanet...@sss.pgh.pa.us 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 Mon, Jun 8, 2009 at 1:38 PM, Grzegorz Jaskiewicz g...@pointblue.com.pl
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
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
in the new
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 br...@momjian.us 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)
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
On Mon, Jun 8, 2009 at 6:58 PM, Simon Riggssi...@2ndquadrant.com 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
Greg Stark st...@enterprisedb.com 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
On Mon, Jun 8, 2009 at 4:30 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Greg Stark st...@enterprisedb.com 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
Robert Haas robertmh...@gmail.com 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.
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
On Mon, Jun 8, 2009 at 7:34 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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 g...@pointblue.com.pl
wrote:
make[3]: *** No rule to make target
72 matches
Mail list logo
