On Sat, May 1, 2010 at 02:23, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Dimitri Fontaine dfonta...@hi-media.com writes:
Peter Eisentraut pete...@gmx.net writes:
I also think that the standards for contrib should not be so lax that a
completely new module can be added after
Hi,
Bruce Momjian írta:
Please add it to the next commit-fest:
https://commitfest.postgresql.org/action/commitfest_view/inprogress
it was already added two days ago:
https://commitfest.postgresql.org/action/patch_view?id=297
Best regards,
Zoltán Böszörményi
--
Bible has answers
On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander mag...@hagander.net wrote:
On Sat, May 1, 2010 at 02:23, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Dimitri Fontaine dfonta...@hi-media.com writes:
Peter Eisentraut pete...@gmx.net writes:
I also think that the standards for contrib
On Mon, 2010-04-26 at 02:45 -0500, Jaime Casanova wrote:
On Mon, Apr 26, 2010 at 2:32 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
How many of the tests in the regular regression suite do anything useful
when run against a standby server? They all have to set up a
On Sat, May 1, 2010 at 7:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-04-26 at 02:45 -0500, Jaime Casanova wrote:
On Mon, Apr 26, 2010 at 2:32 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
How many of the tests in the regular regression suite do anything
On Sat, 2010-05-01 at 09:05 -0500, Jaime Casanova wrote:
maybe we should be using the tables that exists in the regression
database or adding hs_setup_primary in installcheck to prepare the
regression database to run standbycheck in the standby server
That's part of the procedure already.
We
Robert Haas robertmh...@gmail.com writes:
On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander mag...@hagander.net wrote:
A lot of people are not willing to put stuff labeled contrib on
their production boxes.
And as Tom says, even we *ourselves* acknowledge that things in
/contrib are held to a
The thread here
http://archives.postgresql.org/pgsql-admin/2010-04/msg00358.php
shows that current OS X contains the same issue that was complained of
a year or so ago with respect to NetBSD. Namely, that if shmget finds
an existing shared memory segment that is smaller than the current
request,
On Sat, May 1, 2010 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The thread here
http://archives.postgresql.org/pgsql-admin/2010-04/msg00358.php
shows that current OS X contains the same issue that was complained of
a year or so ago with respect to NetBSD. Namely, that if shmget finds
an
Simon Riggs si...@2ndquadrant.com writes:
On Sat, 2010-05-01 at 09:05 -0500, Jaime Casanova wrote:
maybe we should be using the tables that exists in the regression
database or adding hs_setup_primary in installcheck to prepare the
regression database to run standbycheck in the standby server
On Sat, 2010-05-01 at 12:37 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Sat, 2010-05-01 at 09:05 -0500, Jaime Casanova wrote:
maybe we should be using the tables that exists in the regression
database or adding hs_setup_primary in installcheck to prepare the
Simon Riggs si...@2ndquadrant.com writes:
On Sat, 2010-05-01 at 12:37 -0400, Tom Lane wrote:
Where is this test procedure documented?
In src/test/regress/standby_schedule
That's a good way to ensure nobody knows it's there :-(
If you want users to run this, document it in cookbook fashion in
On Sat, 2010-05-01 at 13:12 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Sat, 2010-05-01 at 12:37 -0400, Tom Lane wrote:
Where is this test procedure documented?
In src/test/regress/standby_schedule
That's a good way to ensure nobody knows it's there :-(
If
On Sat, May 1, 2010 at 2:26 PM, Kjell Rune Skaaraas kjell...@yahoo.no wrote:
In other words, pretty much all the hard bits I seem to hear people agree
on exist still apply to the single column. COR for columns was suggested
already back in the same thread in 2005:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander mag...@hagander.net wrote:
A lot of people are not willing to put stuff labeled contrib on
their production boxes.
And as Tom says, even we *ourselves* acknowledge that things in
On Sat, May 1, 2010 at 11:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander mag...@hagander.net wrote:
A lot of people are not willing to put stuff labeled contrib on
their production boxes.
And as Tom says,
Robert Haas wrote:
On Sat, May 1, 2010 at 11:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander mag...@hagander.net
wrote:
A lot of people are not willing to put stuff labeled contrib on
their production
I think the big question is whether we want to provide a binary upgrade
facility for Postgres. If so, pg_migrator is the only facility
currently available, and I can't imagine another option appearing. I
would love for pg_migrator to be easier to use, but I can't figure out
how that can
Bruce Momjian br...@momjian.us writes:
While most of the limitations in previous versions of pg_migrator are
gone, there are still issues with migrating /contrib modules, and there
are many steps to its use.
I think to attain mass usage of pg_migrator, some type of one-click
installer has
Robert Haas robertmh...@gmail.com writes:
On Sat, May 1, 2010 at 11:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think that having it in contrib for a release cycle or so would be
exactly the right approach, actually. Peter's position that it should
be in /bin is fine *once the bugs are out*.
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
While most of the limitations in previous versions of pg_migrator are
gone, there are still issues with migrating /contrib modules, and there
are many steps to its use.
I think to attain mass usage of pg_migrator, some type of
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, May 1, 2010 at 11:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think that having it in contrib for a release cycle or so would be
exactly the right approach, actually. ?Peter's position that it should
be in /bin is fine
Agreed, we're not holding up 9.0 for it. I think the main bit of work
that would be needed to put it into contrib would be to SGML-ize the
docs. Don't know if Bruce has got the time to get that done.
Creating the SGML docs is trivial, especially compared to the 9.0
release notes SGML.
2010/5/1 Bruce Momjian br...@momjian.us:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
While most of the limitations in previous versions of pg_migrator are
gone, there are still issues with migrating /contrib modules, and there
are many steps to its use.
I think to attain mass
C?dric Villemain wrote:
2010/5/1 Bruce Momjian br...@momjian.us:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
While most of the limitations in previous versions of pg_migrator are
gone, there are still issues with migrating /contrib modules, and there
are many steps to its
On Wed, Apr 28, 2010 at 9:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
CREATE OR REPLACE is indeed much more complicated. In fact, for
tables, I maintain that you'll need to link with -ldwim to make it
work properly.
This may in fact be an appropriate way to handle the case for tables,
given
On Fri, Apr 30, 2010 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Scott Bailey arta...@comcast.net writes:
Proposal: Add an invalid flag to pg_class. Invalid objects would be
ignored when doing dependency checks for DDL statements. And an
exception would be thrown when an invalid object is
On Sat, May 1, 2010 at 5:46 PM, Bruce Momjian br...@momjian.us wrote:
Agreed, we're not holding up 9.0 for it. I think the main bit of work
that would be needed to put it into contrib would be to SGML-ize the
docs. Don't know if Bruce has got the time to get that done.
Creating the SGML
Robert Haas wrote:
I don't think it's going
to be practical to retain all the migration code for every pair of
versions forever,
I thought the idea was just to support migration from version N to
version N+1.
cheers
andrew
--
Sent via pgsql-hackers mailing list
On Sat, May 1, 2010 at 11:31 PM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
I don't think it's going
to be practical to retain all the migration code for every pair of
versions forever,
I thought the idea was just to support migration from version N to version
N+1.
I
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
I don't think it's going
to be practical to retain all the migration code for every pair of
versions forever,
I thought the idea was just to support migration from version N to
version N+1.
Yeah. I think trying to do more
On Sat, May 1, 2010 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
To the extent that future bug fixes are relevant to multiple versions
of pg_migrator, we could just apply them to multiple branches, same as
we manage such fixes for the core code. I don't see that trying to
have a single
Robert Haas robertmh...@gmail.com writes:
On Sat, May 1, 2010 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
To the extent that future bug fixes are relevant to multiple versions
of pg_migrator, we could just apply them to multiple branches, same as
we manage such fixes for the core code. I
--- Den fre 2010-04-30 skrev Bruce Momjian br...@momjian.us:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com
writes:
We can artificially make this problem as
complicated as we wish, but
the people who are asking for this feature
(including me) will, I
believe, be quite happy with
34 matches
Mail list logo
