Robert Haas wrote:
On Fri, Apr 30, 2010 at 3:33 AM, Scott Bailey 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 similar to what Oracle
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 s
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 i
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.
>
> M
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
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 mos
Tom Lane wrote:
> Robert Haas 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 l
Robert Haas 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 should only conside
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 hea
On May 2, 2010, at 12:01 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian 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.
>>
>>
Greg Sabino Mullane 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 "foo" d
Tom Lane wrote:
> Bruce Momjian 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
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:
> Andrew Dunstan 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 th
Robert Haas wrote:
> On Sat, May 1, 2010 at 11:31 PM, 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 versio
Bruce Momjian 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 would have
On Sun, 2010-05-02 at 10:34 -0400, Tom Lane wrote:
> Simon Riggs 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
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 o
Simon Riggs 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, it seems like it
Robert Haas wrote:
> On Sat, May 1, 2010 at 5:46 PM, Bruce Momjian 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.
>
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 improvemen
On Fri, 2010-04-30 at 13:41 -0500, Kevin Grittner wrote:
> Heikki Linnakangas 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 reasonable argument, though i
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 ta
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
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
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
26 matches
Mail list logo
