Re: 8.2.0 Tarball vs. REL8_2_0 vs. REL8_2_STABLE

I asked this on a pgcluster forum at pgfoudry a few days ago, but no one
responded:

When I apply pgcluster-1.7.0rc1-patch to Postgres REL8_2_STABLE I get a
handful of rejects. Is this to be expected, or should I be applying
against some different source?

> > I asked this on a pgcluster forum at pgfoundry a few days ago, but
> > no one responded
>
> I suspect that pgcluster has become obsoleted and no longer
> maintained.

Well, a patch for 8.2 was released on pgfoundry 7-Dec-2006.

> I suggest looking at pgpool-II and/or slony1 ... Also, the High
> Availability documentation

Thanks for those pointers, I will follow up on those. However, for some
time I've been enamored of pgcluster. I really want to make a go of it,
but I am concerned that, although not abandoned, the pgcluster project
is not as active as I'd hoped. I'd like to contribute, but I want to
get the stuff running first.

> 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(at)dunslane(dot)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

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(at)mattmillersf(dot)fastmail(dot)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