SEO

> 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?

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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/

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

> > 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?

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

> > 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?

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

"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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend