Thread: 8.2.0 Tarball vs. REL8_2_0 vs. REL8_2_STABLE (was: [GENERAL] pgcluster-1.7.0rc1-patch)
8.2.0 Tarball vs. REL8_2_0 vs. REL8_2_STABLE (was: [GENERAL] pgcluster-1.7.0rc1-patch)
From
"Matt Miller"
Date:
> When I apply pgcluster-1.7.0rc1-patch to Postgres REL8_2_STABLE I get > a handful of rejects. The patch applies to the 8.2.0 tarball without rejects and without fuzz. That's good. Now on to some fun with pgcluster... However, the patch will not apply to cvs branch REL8_2_0. This all raises the question: what's the difference between REL8_2_STABLE, REL8_2_0, and the 8.2.0 tarball?
Matt Miller wrote: >> When I apply pgcluster-1.7.0rc1-patch to Postgres REL8_2_STABLE I get >> a handful of rejects. >> > > The patch applies to the 8.2.0 tarball without rejects and without > fuzz. That's good. Now on to some fun with pgcluster... > > However, the patch will not apply to cvs branch REL8_2_0. This all > raises the question: what's the difference between REL8_2_STABLE, > REL8_2_0, and the 8.2.0 tarball? > > > STABLE doesn't mean static. It's the branch for what will be the 8.1.x series. But REL8_2_0 should correspond pretty closely to the tarball, I believe. Until we see the rejects it's hard to tell what the problem is, though. cheers andrew
Andrew Dunstan wrote: > Matt Miller wrote: > >>When I apply pgcluster-1.7.0rc1-patch to Postgres REL8_2_STABLE I get > >>a handful of rejects. > > > >The patch applies to the 8.2.0 tarball without rejects and without > >fuzz. That's good. Now on to some fun with pgcluster... > > > >However, the patch will not apply to cvs branch REL8_2_0. This all > >raises the question: what's the difference between REL8_2_STABLE, > >REL8_2_0, and the 8.2.0 tarball? > > STABLE doesn't mean static. It's the branch for what will be the 8.1.x > series. But REL8_2_0 should correspond pretty closely to the tarball, I > believe. Until we see the rejects it's hard to tell what the problem is, > though. I've been told that the pgcluster patch patches some generated files (parse.h and other apparently). It would be no surprise that it failed on those. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Andrew Dunstan <andrew@dunslane.net> writes:
> Matt Miller wrote:
>> However, the patch will not apply to cvs branch REL8_2_0. This all
>> raises the question: what's the difference between REL8_2_STABLE,
>> REL8_2_0, and the 8.2.0 tarball?
> STABLE doesn't mean static. It's the branch for what will be the 8.1.x
> series. But REL8_2_0 should correspond pretty closely to the tarball, I
> believe.
REL8_2_0 is a tag, not a branch, and should correspond *exactly* to the
contents of the 8.2.0 tarball. The REL8_2_STABLE branch by now contains
a number of bug fixes, but that would only cause a patch failure if the
patch were trying to tweak one of the code sections changed for bug
fixing, which seems a tad unlikely.
> Until we see the rejects it's hard to tell what the problem is,
> though.
Yeah, this is all pretty meaningless without seeing the rejects.
regards, tom lane
Re: 8.2.0 Tarball vs. REL8_2_0 vs. REL8_2_STABLE (was: [GENERAL] pgcluster-1.7.0rc1-patch)
From
Peter Eisentraut
Date:
Matt Miller wrote: > However, the patch will not apply to cvs branch REL8_2_0. This all > raises the question: what's the difference between REL8_2_STABLE, > REL8_2_0, and the 8.2.0 tarball? REL8_2_0 is the tag from with the 8.2.0 tarball was built. REL8_2_STABLE is the branch that, having started at REL8_2_0, will eventually produce 8.2.1 and so on. -- Peter Eisentraut http://developer.postgresql.org/~petere/
> > difference between REL8_2_STABLE, REL8_2_0 > > STABLE doesn't mean static. It's the branch for what will be the > 8.1.x series. Okay, and this is all different from HEAD, which will presumably become 8.3, correct?
Matt Miller wrote: >>> difference between REL8_2_STABLE, REL8_2_0 >>> >> STABLE doesn't mean static. It's the branch for what will be the >> 8.1.x series. >> > > Okay, and this is all different from HEAD, which will presumably become > 8.3, correct? > > Yes. Of course, I should have said 8.2.x above. cheers andrew
> > The [pgcluster-1.7.0rc1-patch] patch applies to the 8.2.0 tarball ... > > However, the patch will not apply to cvs branch REL8_2_0. > > I've been told that the pgcluster patch patches some generated files > (parse.h and other apparently). Yes, I could not at first apply to REL8_2_0 because the patch file wanted to patch src/backend/parser/gram.c. At that point I started over with a fresh REL8_2_0, ran "./configure; make", and tried the patch again. That's when I got a bunch of failures and fuzz. The problem files are: src/backend/parser/gram.c src/backend/parser/parse.h src/interfaces/libpq/libpq.rc So, I suppose libpq.rc is a derived file, also? Now I have two questions. First, why does pgcluster patch derived files? Is this just sloppy/lazy technique, or could there be some deeper reason? I realize this is properly to be posed to the pgcluster folks, but they don't seem to be too responsive, at least not to their pgfoundry forums. Second, does it make sense that the derived files that rejected the patch would be so different between the 8.2.0 tarball and my REL8_2_0 build?
"Matt Miller" <pgsql@mattmillersf.fastmail.fm> writes:
> Yes, I could not at first apply to REL8_2_0 because the patch file
> wanted to patch src/backend/parser/gram.c. At that point I started over
> with a fresh REL8_2_0, ran "./configure; make", and tried the patch
> again. That's when I got a bunch of failures and fuzz. The problem
> files are:
This most likely means that you have a different version of bison
installed than was used to build the release tarballs.
> Now I have two questions. First, why does pgcluster patch derived
> files?
I suppose because they think people might not have bison installed,
but on the whole it's a pretty bad idea.
regards, tom lane
Matt Miller írta: >>> The [pgcluster-1.7.0rc1-patch] patch applies to the 8.2.0 tarball ... >>> However, the patch will not apply to cvs branch REL8_2_0. >>> >> I've been told that the pgcluster patch patches some generated files >> (parse.h and other apparently). >> > > Yes, I could not at first apply to REL8_2_0 because the patch file > wanted to patch src/backend/parser/gram.c. At that point I started over > with a fresh REL8_2_0, ran "./configure; make", and tried the patch > again. That's when I got a bunch of failures and fuzz. The problem > files are: > > src/backend/parser/gram.c > src/backend/parser/parse.h > src/interfaces/libpq/libpq.rc > > So, I suppose libpq.rc is a derived file, also? > > Now I have two questions. First, why does pgcluster patch derived > files? Is this just sloppy/lazy technique, or could there be some > Exactly. E.g. PGCluster patches configure, not configure.in, among others. The sugar on the top is PGCluster ruins the nice portability of PostgreSQL. E.g. plain usage of fork() without considering EXEC_BACKEND is not portable across archs. > deeper reason? I realize this is properly to be posed to the pgcluster > folks, but they don't seem to be too responsive, at least not to their > pgfoundry forums. > > Second, does it make sense that the derived files that rejected the > patch would be so different between the 8.2.0 tarball and my > REL8_2_0 build? > If the autotools and bison is different, they may certainly produce different files. Best regards, Zoltán Böszörményi