Bruce Momjian writes:
> I think the cleanest solution is to document that these issues might
> happen and suggest solutions.
No, the cleanest solution is to fix it before people ever see a
problem. This is trivial to do in the case of dblink and I don't
see why you think it would be better to ma
Josh Berkus wrote:
> On 6/5/09 6:27 PM, Bruce Momjian wrote:
> > Josh Berkus wrote:
> >> Bruce,
> >>
> >> Assuming a contrib module *hasn't* changed its API, does pg_migrator
> >> link against the 8.4 version of the module's .so, or the old 8.3 version?
> >
> > 8.4 version, or whatever is in the 8.
Tom Lane wrote:
> Josh Berkus writes:
> > So, here's what we need for 8.3 --> 8.4 for contrib modules:
>
> > 1) make a list of contrib modules which do not convert cleanly (testers?)
> > 2) document these.
> > 3) give pg_migrator some hackish way to install 8.4 contrib modules from
> > source be
Grzegorz Jaskiewicz wrote:
>
> On 6 Jun 2009, at 19:50, Tom Lane wrote:
> > We have five days.
> >
> > I don't think we need testing, per se. The first step should be to
> > diff
> > the 8.3 and 8.4 versions of the various contrib .sql.in files and
> > determine what changed. Any module whose
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. (ip4
Joe Conway writes:
> Tom Lane wrote:
>> But that reminds me, weren't you going to add something to force
>> libpq to set client_encoding to the database encoding?
> I think the attached is what you had in mind.
Looks plausible to me.
> But I don't know right off
> how to trigger the failure (a
Tom Lane wrote:
But that reminds me, weren't you going to add something to force
libpq to set client_encoding to the database encoding?
I think the attached is what you had in mind. But I don't know right off
how to trigger the failure (and therefore how to test the solution). A
naive test wi
Tom Lane wrote:
Any revision control system should be able to do better than diff/patch
as these systems have more information available to them. Normal GIT
uses the relatively common 3-way merge based upon the most recent common
ancestor algorithm. Assuming there is a most recent common ancest
Hi,
Greg Stark wrote:
> For what it's worth that's certainly not true. Any user maintaining a
> patched version of the source tree for production use will want to
> merge in any patches for older releases. For example anyone using the
> CONNECT BY patch with 8.3 will surely want to take any 8.3 pa
Hi,
Tom Lane wrote:
> How robust is git about dealing with whitespace changes,
> nearby variable renamings, and such?
Monotone tracks changes line by line. I'm not sure about git. Kdiff3,
which is used to do the manual merge, if necessary, uses some finer
grained method, AFAIK.
However, there's
I wrote:
> Another interesting question is why successive vacuums aren't causing
> the index reltuples counts to go to zero. Shouldn't a partial vacuum
> result in *all* pages of the relation being marked as not needing to
> be examined by the next vacuum?
I figured out the reason for that: the f
Hi,
Andrew Dunstan wrote:
> One fact to keep in mind is that, unlike most other FOSS projects, we
> keep quite a large number of branches live.
So far I thought exactly that would be a good reason for migrating to
something like git. Those claim to ease working on multiple branches in
parallel, a
Hi,
Tom Lane wrote:
> There are a number of possible reasons, but here are a few that hold for me:
Thank you for this very good collection. I'm still wondering about
what's the best way to represent this in git (or others). Cherry-picking
is arguably the simplest variant. Maybe that can be combin
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, prefix, hstore-new, or
Tom Lane wrote:
Any revision control system should be able to do better than diff/patch
as these systems have more information available to them. Normal GIT
uses the relatively common 3-way merge based upon the most recent common
ancestor algorithm. Assuming there is a most recent common ance
I complained a couple days ago that in HEAD, vacuum is putting
very bogus values into pg_class.reltuples for indexes:
http://archives.postgresql.org/pgsql-bugs/2009-06/msg00037.php
After looking through the code a bit, I've confirmed my prior guess that
this is caused by the partial-vacuum patch.
On 6 Jun 2009, at 19:50, Tom Lane wrote:
We have five days.
I don't think we need testing, per se. The first step should be to
diff
the 8.3 and 8.4 versions of the various contrib .sql.in files and
determine what changed. Any module whose .sql.in file hasn't changed
is definitely safe.
I
Tom Lane wrote:
Joe Conway writes:
OK, got it. I think the attached is what you're looking for, although I
have not yet tested beyond "it compiles" and "it passes make installcheck".
You're making it vastly overcomplicated. Just do something like
for (cp = str; *cp; cp++)
{
Mark,
On the DL380 GB system, where I'm using a lot more drives the Jignesh,
I see a performance change of under 5%. 15651.14 notpm vs 16333.32
notpm. And this is after a bit of tuning, not sure how much the out
of the box experience changes on this system.
Well, Jignesh and I identified two
Josh Berkus writes:
> So, here's what we need for 8.3 --> 8.4 for contrib modules:
> 1) make a list of contrib modules which do not convert cleanly (testers?)
> 2) document these.
> 3) give pg_migrator some hackish way to install 8.4 contrib modules from
> source before copying over the database
On 6/5/09 6:27 PM, Bruce Momjian wrote:
Josh Berkus wrote:
Bruce,
Assuming a contrib module *hasn't* changed its API, does pg_migrator
link against the 8.4 version of the module's .so, or the old 8.3 version?
8.4 version, or whatever is in the 8.4 lib, which should be 8.4.
So, here's what w
Joe Conway writes:
> OK, got it. I think the attached is what you're looking for, although I
> have not yet tested beyond "it compiles" and "it passes make installcheck".
You're making it vastly overcomplicated. Just do something like
for (cp = str; *cp; cp++)
{
Tom Lane wrote:
Joe Conway writes:
Tom Lane wrote:
you will need to whip up a special-purpose quoting subroutine.
OK, I see that. I assume I need to care for encoding issues? If so, do I
assume server encoding or client encoding?
Hoo, good point. You can assume the database (server) enco
On Fri, May 22, 2009 at 10:38 AM, Tom Lane wrote:
> Greg Smith writes:
>> Yesterday Jignesh Shah presented his extensive benchmark results comparing
>> 8.4-beta1 with 8.3.7 at PGCon:
>> http://blogs.sun.com/jkshah/entry/pgcon_2009_performance_comparison_of
>
>> While most cases were dead even or a
On Fri, Jun 5, 2009 at 4:37 PM, Tom Lane wrote:
>
> However, given that we don't do any real development on the back
> branches, it might be that trying to be smart about this is a waste of
> time anyway. Surely only the HEAD version of the patch is going to be
> something that other developers ca
Mark Mielke writes:
> Tom Lane wrote:
>> I have heard it claimed that git is more intelligent than plain
>> diff/patch and could successfully merge patches in cases that currently
>> require manual adjustment of the sort Andrew describes.
>> ...
>> However, I have yet to see any actual *evidence*
Tom Lane wrote:
I have heard it claimed that git is more intelligent than plain
diff/patch and could successfully merge patches in cases that currently
require manual adjustment of the sort Andrew describes. If that's
really true to any significant extent, then it could represent a benefit
large
Joe Conway writes:
> Tom Lane wrote:
>> you will need to whip up a special-purpose quoting subroutine.
> OK, I see that. I assume I need to care for encoding issues? If so, do I
> assume server encoding or client encoding?
Hoo, good point. You can assume the database (server) encoding, because
Tom Lane wrote:
The quoting logic is still completely the wrong thing :-(. For one
thing, quote_literal will try to generate E'' syntax in some cases.
But more to the point, quote_literal's quoting rules don't match
what is needed. A look at libpq's conninfo_parse says that what it
accepts is s
Andrew Dunstan writes:
> [ most of a good summary omitted ]
> ... Even fairly trivial patches can suffer
> from this: the pretty small plperl fixes I applied yesterday and the day
> before, required adjustment going from one branch to the previous one in
> about three out of five back branch ca
Markus Wanner wrote:
Hi,
Andrew Dunstan wrote:
Yeah, a requirement to work from the back branch forward is quite
unacceptable IMNSHO. It's also quite unreasonable.
The monotone page about daggy fixes does quite a good job in explaining
why it is helpful. I think it's how to make bes
Markus Wanner writes:
> Out of interest, and not necessarily related to Postgres: why do you
> think it's unreasonable? Fixing the problem where it was introduced
> sounds like the most reasonable place to fix it, IMO.
There are a number of possible reasons, but here are a few that hold for me:
Joe Conway writes:
> Based on Tom's post today about RC1, it sounds like I need to get this
> committed very soon. Any complaints?
The quoting logic is still completely the wrong thing :-(. For one
thing, quote_literal will try to generate E'' syntax in some cases.
But more to the point, quote_
Hi,
Andrew Dunstan wrote:
> Yeah, a requirement to work from the back branch forward is quite
> unacceptable IMNSHO. It's also quite unreasonable.
The monotone page about daggy fixes does quite a good job in explaining
why it is helpful. I think it's how to make best use of these tools. And
it's
Hi,
Tom Lane wrote:
> I think it's already been made crystal clear that the people who
> actually do this work don't do it that way, and are uninterested in
> allowing their tools to force them to do it that way.
That's well understood.
> Patching from
> HEAD back works better for us for a numbe
Bruce Momjian wrote:
> Now that pg_migrator is in beta (http://pgfoundry.org/frs/?group_id=1000235),
> I was wondering if we want to mention pg_migrator anywhere in our docs
> or release notes? Josh Berkus is already mentioning it in the draft
> press release.
Having gotten no replies I assume
Based on Tom's post today about RC1, it sounds like I need to get this
committed very soon. Any complaints?
Joe
Original Message
Subject: Re: [HACKERS] dblink patches for comment
Date: Tue, 02 Jun 2009 16:08:18 -0700
From: Joe Conway
Tom Lane wrote:
The docs patch looks ok
37 matches
Mail list logo
