On lör, 2010-05-01 at 17:26 -0400, Bruce Momjian wrote:
I am unclear why it would be in /bin if it requires 15 steps to run
and is run only once by only some users. It seems natural
for /contrib, like pgcrypto.
Well, pg_resetxlog is also rarely run by most users. It started in
contrib but
Hackers,
I'm interested in tackling some of the todo items in XML category. Being
new to postgres hacking I'm hoping I chose an item that isn't more than
I can chew in the first sitting. One item that has caught my eye that I
(naively) hope isn't a huge todo is:
xpath_exists() is needed. It
Recent changes to parameters aren't yet sufficiently well documented and
I'd like to see this improved by the authors of those patches. I accept
the behaviour changes, but we need full docs to explain them.
* hot_standby doesn't mention that wal_level = hot_standby is also
required, nor is there
On Wed, 2009-07-22 at 01:21 +, Tom Lane wrote:
Tweak TOAST code so that columns marked with MAIN storage strategy are
not forced out-of-line unless that is necessary to make the row fit on a
page. Previously, they were forced out-of-line if needed to get the row
down to the default
On Fri, 2010-04-30 at 13:41 -0500, Kevin Grittner wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Yeah, min_wal_segments or something would make sense.
Surely it would confuse people to see they have fewer than
min_wal_segments WAL segments.
That does sound like a
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
This can definitely use some improvement
Robert Haas wrote:
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
Simon Riggs si...@2ndquadrant.com writes:
Not commenting further on that patch, but I notice that when we UPDATE
the toasting algorithm takes no account of the available freespace on
the current block. If we are updating and the space available would make
a difference to the row length chosen,
Andrew Dunstan 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.
Oh, I will also support many older _source_
On Sun, 2010-05-02 at 10:34 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
Not commenting further on that patch, but I notice that when we UPDATE
the toasting algorithm takes no account of the available freespace on
the current block. If we are updating and the space
Bruce Momjian br...@momjian.us writes:
Andrew Dunstan wrote:
I thought the idea was just to support migration from version N to
version N+1.
Oh, I will also support many older _source_ versions, like 8.3 and 8.4.
Really? Nobody else has bought into that, and it's not only pg_migrator
that
Robert Haas wrote:
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
Tom Lane wrote:
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
Use case: when running a process that populates many inherited
tables across schemas, having one fail gives the unhelpful
error message:
ERROR: invalid input syntax for integer: abc
CONTEXT: COPY foo, line 1, column a: abc
Unhelpful because foo does not uniquely identifies the table
or
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Andrew Dunstan wrote:
I thought the idea was just to support migration from version N to
version N+1.
Oh, I will also support many older _source_ versions, like 8.3 and 8.4.
Really? Nobody else has bought into that, and it's
Greg Sabino Mullane g...@turnstep.com writes:
Use case: when running a process that populates many inherited
tables across schemas, having one fail gives the unhelpful
error message:
ERROR: invalid input syntax for integer: abc
CONTEXT: COPY foo, line 1, column a: abc
Unhelpful because
On May 2, 2010, at 12:01 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Andrew Dunstan wrote:
I thought the idea was just to support migration from version N to
version N+1.
Oh, I will also support many older _source_ versions, like 8.3 and
Robert Haas wrote:
My guess is that when that happens we would just document/enforce it
in
pg_migrator, but I don't see why we would arbitrarily restrict
pg_migrator at this time.
Yeah. It's not uncommon to want to upgrade by more than one release at
a time, and I haven't heard any
Robert Haas robertmh...@gmail.com writes:
Yeah. It's not uncommon to want to upgrade by more than one release at
a time, and I haven't heard any reason why we should arbitrarily
refuse to support that. Of course we may need to do that eventually
for some specific reason, but it seems like we
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah. It's not uncommon to want to upgrade by more than one release at
a time, and I haven't heard any reason why we should arbitrarily
refuse to support that. Of course we may need to do that eventually
for some specific reason,
Peter Eisentraut wrote:
On l?r, 2010-05-01 at 17:26 -0400, Bruce Momjian wrote:
I am unclear why it would be in /bin if it requires 15 steps to run
and is run only once by only some users. It seems natural
for /contrib, like pgcrypto.
Well, pg_resetxlog is also rarely run by most users.
Simon Riggs wrote:
Recent changes to parameters aren't yet sufficiently well documented and
I'd like to see this improved by the authors of those patches. I accept
the behaviour changes, but we need full docs to explain them.
* hot_standby doesn't mention that wal_level = hot_standby is
Bruce Momjian wrote:
Well, that is going to make the documentation more complicated than it
already is. Why mention a process in 9.0 that no one needs to use? I
am not writing the docs for some hypothetical release, but for 9.0.
When we have some restriction, we can document that.
My
Bruce Momjian wrote:
For example, I assume there
will be some major version of Postgres where pg_migrator will not work
at all.
We need to be thinking more now about such a contingency. Postgres use
in very large installations is now at such a level that requiring a
pg_dump/pg_restore
Andrew Dunstan wrote:
Bruce Momjian wrote:
For example, I assume there
will be some major version of Postgres where pg_migrator will not work
at all.
We need to be thinking more now about such a contingency. Postgres use
in very large installations is now at such a level
Robert Haas wrote:
On Fri, Apr 30, 2010 at 3:33 AM, Scott Bailey arta...@comcast.net wrote:
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 called.
This is
26 matches
Mail list logo
