Re: rename() vs. link(); building from source

Hello, everyone.

I've been using PostgreSQL successfully on Cygwin for some time. I've
recently gotten into some applications which require me to load a large
amount of data, so I ran into the error that's been discussed around here
with the inability to recycle the transaction log files:

http://archives.postgresql.org/pgsql-cygwin/2002-04/msg00031.php

The effects of this issue have been quite frustrating to me ... I have to
start my data load and stop back every once in a while to restart it (rather
than leaving it run overnight). I eventually got annoyed enough to decide
to fix it.

* * *

I saw that the fix had been proposed on the list (I found a Geocrawler page
via Google), and it seemed reasonable to me. I decided to see if I could
upgrade and get the fix. Checking the CVS source, I saw that our patch
hasn't made it in yet (although almost precisely the same patch just got
done for NetWare), so I decided "I'll build PostgreSQL from source, and
patch it myself!"

* * *

Got the source from CVS. I attempted to build it with the default options
(not the options used for the Cygwin package distribution).

Bear in mind that I am inexpert at UNIX, poor at C, and absolutely
incompetent at make. Thus, I'm really bad at debugging build problems.
(And if you decide to help me, you'll have to be patient with me when
explaining what's going on.)

So, for the benefit of all, here's what I got:

configure went fine, all automated; no changes.

When I attempted make, I got an error having to do with bison (which luckily
had a very easy error message, since I know absolutely nothing about lex and
yacc except what they're used for):

make[3]: Entering directory
`/cygdrive/c/projects/local/external/pgsql/src/backend/parser'
bison -y -d gram.y
bison: /usr/share/bison.simple: No such file or directory
make[3]: *** [parse.h] Error 2

Well, a little checking revealed that there is a
/usr/share/bison/bison.simple in Cygwin. Without having any idea what I was
doing, this worked:

ln /usr/share/bison/bison.simple /usr/share/bison.simple

Re-running make got me lots farther (through the whole src/access tree), but
I got stopped here:

make[3]: Entering directory
`/cygdrive/c/projects/local/external/pgsql/src/backend/bootstrap'
bison -y -d bootparse.y
sed -e 's/^yy/Int_yy/g' -e 's/\([^a-zA-Z0-9_]\)yy/\1Int_yy/g' < y.tab.c >
./bootparse.c
sed -e 's/^yy/Int_yy/g' -e 's/\([^a-zA-Z0-9_]\)yy/\1Int_yy/g' < y.tab.h >
./bootstrap_tokens.h
rm -f y.tab.c y.tab.h
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I. -I../../../src
/include -I/usr/local/include -DBUILDING_DLL=1 -c -o bo
otparse.o bootparse.c
bootparse.y:266: invalid format `#line' directive
bootparse.y:582: invalid format `#line' directive
bootparse.y:1089: warning: `/*' within comment
bootparse.y:339: unterminated character constant
bootparse.y:372: invalid format `#line' directive
make[3]: *** [bootparse.o] Error 1

I don't really have the skills to fix this error ... I looked in bootparse.c
and saw how gcc is getting to bootparse.y in the first place:

#line 80 "bootparse.y"

I don't know what this C preprocessor directive means, so I don't know
exactly how to continue.

$ gcc --version
2.95.3-5

Without including lots of cygcheck debris, I'll just say that my Cygwin
distribution is quite recent unless someone needs more detail than that.

* * *

I did find the /usr/doc/Cygwin/postgresql-7.2.README ... I was intrigued by
the section "Source." I figured that some combination of build.sh, etc.,
would do it for me ... the file says PostgreSQL builds out of the box with a
perl-related caveat and I wasn't going to build perl, so I was hopeful. I
was even more excited by:

See CYGWIN-PATCHES/build.sh in the source archive for my exact build
recipe for configuring, making, and packaging this distribution.

However, try as I might, I can't figure out what that refers to. I've
looked under both the PostgreSQL source tree (thoroughly) and the Cygwin
source tree (not as thoroughly), done net searches, and can't find any
matches for "CYGWIN-PATCHES" ... so I'm stuck there for the moment.

* * *

I was also inspired by my discovery of the pgsql-cygwin mailing list
archives, because I figured building from source has got to be one of the
most common discussion topics, right? Wow, I couldn't find anyone trying to
do it in the last few months! My view is that this is a tribute to both
Jason for his package and the folks at Red Hat for their Cygwin install
program.

* * *

So anyway, as for me, I just want to fix my problem. If we can get the
original patch committed, that would be great for me; if I can successfully
build from source (which may be perfectly well laid-out in that
CYGWIN-PATCHES stuff, if I knew where to find it), that's great too. I
wanted to make sure that I described everything I've done so far because I
thought some parts might be of general interest ... my apologies if they're
not.

-- David.

David P. Caldwell wrote:
>
> I did find the /usr/doc/Cygwin/postgresql-7.2.README ... I was intrigued by
> the section "Source." I figured that some combination of build.sh, etc.,
> would do it for me ... the file says PostgreSQL builds out of the box with a
> perl-related caveat and I wasn't going to build perl, so I was hopeful. I
> was even more excited by:
>
> See CYGWIN-PATCHES/build.sh in the source archive for my exact build
> recipe for configuring, making, and packaging this distribution.
>
> However, try as I might, I can't figure out what that refers to. I've
> looked under both the PostgreSQL source tree (thoroughly) and the Cygwin
> source tree (not as thoroughly), done net searches, and can't find any
> matches for "CYGWIN-PATCHES" ... so I'm stuck there for the moment.

If install the PostgreSQL source by way of the Cygwin installer, you should
find the CYGWIN-PATCHES directory in a /usr/src/postgresql-7.2.1-1 directory

IIRC, all you have to do to build (assuming you have all other necessary
cygwin packages installed - gcc, etc) is cd to the above mentioned directory
and run: CYGWIN-PATCHES/build.sh 7.2.1 1

(those last 2 params are the version and port number, which the build.sh
expects as arguments, I don't recall offhand exactly why, but things seemed to
go smoother later on if I kept the same port number as what the -real- cygwin
postgresql package was)

When I tried it (to do the unlink/rename change), I tweaked the build.sh line
27 to remove --with-perl and --with-python from the configure args. Other
than that, it built out-of-the-box pretty much as advertised (and the
recycling transaction logs problem went away in my case).

Barry

Barry,

On Sat, May 11, 2002 at 11:24:42PM -0500, Barry Pederson wrote:
> IIRC, all you have to do to build (assuming you have all other necessary
> cygwin packages installed - gcc, etc) is cd to the above mentioned
> directory and run: CYGWIN-PATCHES/build.sh 7.2.1 1
>
> (those last 2 params are the version and port number, which the build.sh
> expects as arguments, I don't recall offhand exactly why, but things seemed
> to go smoother later on if I kept the same port number as what the -real-
> cygwin postgresql package was)

The port (i.e. package) number is free to change. It only affects the
"-x" (e.g., "-1") in the tarball names -- that's it.

> When I tried it (to do the unlink/rename change), I tweaked the build.sh
> line 27 to remove --with-perl and --with-python from the configure args.
> Other than that, it built out-of-the-box pretty much as advertised (and the
> recycling transaction logs problem went away in my case).

Did you use the (exact) patch at the end of:

http://archives.postgresql.org/pgsql-cygwin/2002-04/msg00057.php

If so, then please confirm this fact and I will submit this patch to
pgsql-patches for consideration. If not, then please try again with
this (exact) patch. If you are still successful, then I will submit it.

I need this assistance, because I cannot (easily) reproduce this problem
myself.

Thanks,
Jason

Barry:

Thanks!

As for the general interest stuff:

To continue the blow-by-blow, I used the Cygwin installer to get the latest
source, and it contained the extra directory as promised.

I was surprised when I examined it ... the script didn't seem to be doing
anything magical that I wasn't. (Run configure, run make ...)

At first, I was unable to use build.sh to build because I didn't have ant
installed and/or set up. After downloading, setting the JAVA_HOME and
ANT_HOME variables, and adding ANT_HOME/bin to the path, that worked.

The next problem I ran into had to do with Python. Unfortunately, I never
solved it (see below), so I don't know exactly what caused it. At the time
that build.sh was running, it was detecting Python 2.1, correctly.
(python -V gave "2.1.1" or something). However, there was no
/usr/include/python2.1, only /usr/include/python2.2, on my system. I tried
my symlink trick to get it to work, but there are apparently
incompatibilities between the headers or libraries, because it still blew up
with undefined something or other (I wish I had saved the error message). I
downgraded to python2.1 through the installer, but that didn't fix it
either, then upgraded to 2.2, and that didn't do it either. I gave up at
that point.

Seeing that the build.sh script was rather simple, I decided to return to
the CVS snapshot I had gotten from postgresql.org. I figured that would be
superior from an administration point of view anyway, because CVS would make
it easier for me to deal with patches, etc. I also decided to go with
minimalist options, so I just ran configure --enable-multibyte --with-java.

I noticed that running build.sh did not exhibit the error I complained about
in my earlier E-mail (with some yacc error), so it occurred to me to check
the source for that file in CVS. Sure enough, it had been updated since
7.2.1 ... so I think I can report that the current development tree doesn't
build on Cygwin for that reason. (Having run both builds, I also notice
that someone has been going through and fixing lots of bison warnings, so
the error was probably introduced then.) I grabbed the 7.2.1 release from
CVS instead (somewhat counterintuitively tagged REL7_2_STABLE rather than
REL7_2_1).

At that point, I had some readline problems (unresolved symbols), so I
downgraded my readline to 4.2-3 from 4.2a-1. That didn't work, so I
re-upgraded to 4.2a-1 and ran make again ... and it worked! No explanation
for how that happened, though I notice now there are separate libreadline4
and libreadline5 packages in addition, so maybe there are some complexities
involved that I don't fully grasp.

Finally, I edited my source file, ran make again, and everything is fine.
Here's the diff:

Index: xlog.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/access/transam/xlog.c,v
retrieving revision 1.86.2.1
diff -r1.86.2.1 xlog.c
1509c1509
< #ifndef __BEOS__
---
> #if !defined(__BEOS__) && !defined(__CYGWIN__) && !defined(N_PLAT_NLM)

I added the !defined(N_PLAT_NLM) because that's been added to the source
tree since 7.2.1, to support NetWare (according to the CVS log message).

Anyway, thanks to Barry again for the help, and I hope something from this
narrative helps someone else at some point. I apologize for not documenting
the steps better ... I should have been focusing on keeping a log, but I got
impatient.

-- David.

-----Original Message-----
From: Barry Pederson [mailto:bp(at)barryp(dot)org]
Sent: Sunday, May 12, 2002 12:25 AM
To: David P. Caldwell
Cc: pgsql-cygwin(at)postgresql(dot)org
Subject: Re: [CYGWIN] rename() vs. link(); building from source

David P. Caldwell wrote:
>
> I did find the /usr/doc/Cygwin/postgresql-7.2.README ... I was intrigued
by
> the section "Source." I figured that some combination of build.sh, etc.,
> would do it for me ... the file says PostgreSQL builds out of the box with
a
> perl-related caveat and I wasn't going to build perl, so I was hopeful. I
> was even more excited by:
>
> See CYGWIN-PATCHES/build.sh in the source archive for my exact build
> recipe for configuring, making, and packaging this distribution.
>
> However, try as I might, I can't figure out what that refers to. I've
> looked under both the PostgreSQL source tree (thoroughly) and the Cygwin
> source tree (not as thoroughly), done net searches, and can't find any
> matches for "CYGWIN-PATCHES" ... so I'm stuck there for the moment.

If install the PostgreSQL source by way of the Cygwin installer, you should
find the CYGWIN-PATCHES directory in a /usr/src/postgresql-7.2.1-1 directory

IIRC, all you have to do to build (assuming you have all other necessary
cygwin packages installed - gcc, etc) is cd to the above mentioned directory
and run: CYGWIN-PATCHES/build.sh 7.2.1 1

(those last 2 params are the version and port number, which the build.sh
expects as arguments, I don't recall offhand exactly why, but things seemed
to
go smoother later on if I kept the same port number as what the -real-
cygwin
postgresql package was)

When I tried it (to do the unlink/rename change), I tweaked the build.sh
line
27 to remove --with-perl and --with-python from the configure args. Other
than that, it built out-of-the-box pretty much as advertised (and the
recycling transaction logs problem went away in my case).

Barry

Jason:

Unfortunately, I hit send just minutes before receiving your e-mail.

Maybe we should revise the patch to reflect the current source tree? I'm
not at all familiar with protocol in this case, but if you want me to do
something, let me know.

Of course, I suppose I should confirm that my install is working first ...
:)

-- David.

-----Original Message-----
From: Jason Tishler [mailto:jason(at)tishler(dot)net]
Sent: Sunday, May 12, 2002 10:18 AM
To: Barry Pederson
Cc: David P. Caldwell; pgsql-cygwin(at)postgresql(dot)org
Subject: Re: [CYGWIN] rename() vs. link(); building from source

Barry,

[snip]

Did you use the (exact) patch at the end of:

http://archives.postgresql.org/pgsql-cygwin/2002-04/msg00057.php

If so, then please confirm this fact and I will submit this patch to
pgsql-patches for consideration. If not, then please try again with
this (exact) patch. If you are still successful, then I will submit it.

I need this assistance, because I cannot (easily) reproduce this problem
myself.

Thanks,
Jason

Jason Tishler wrote:
> Barry,
>
> Did you use the (exact) patch at the end of:
>
> http://archives.postgresql.org/pgsql-cygwin/2002-04/msg00057.php
>
> If so, then please confirm this fact and I will submit this patch to
> pgsql-patches for consideration. If not, then please try again with
> this (exact) patch. If you are still successful, then I will submit it.

I've been using my own equivalent patch, but in the interest of getting this
thing hopefully fixed, I've used your patch and it still works.

Below is a blow-by-blow account of exactly what I did to test this:

===================================================
Edited CYGWIN-PATCHES/build.sh to remove

--with-python --with-perl --with-java

from the configure args.

-------------------
Ran the commands:

cd /usr/src/postgresql-7.2.1-1
CYGWIN-PATCHES/build.sh 7.2.1 1

which created a file named: postgresql-7.2.1-1.tar.bz2
in the current directory

bzip2 -d postgresql-7.2.1-1.tar.bz2
cd /
tar xvf /usr/src/postgresql-7.2.1-1/postgresql-7.2.1-1.tar

decompressed and installed what I had built

initdb -D /d/pgtest
postmaster -D /d/pgtest

Created a new database cluster, and started the server using that
cluster. Then in another window with a dump of a roughly 100mb large object:

createdb test
pg_restore -d test -v -Ft biglo.pgdump.tar
dropdb test
createdb test
pg_restore -d test -v -Ft biglo.pgdump.tar

and the backend stopped, complaining about Permission denied on link.
(maybe if my dump of a large object was bigger, I wouldn't have to do it
twice to cause the crash).

------------------------

So, having confirmed that my stock build would crash, applied Jason's
*exact* patch from

http://archives.postgresql.org/pgsql-cygwin/2002-04/msg00057.php

removed the old postgresql-7.2.1-1.tar file from the original build and the
old database cluster

re-ran the exact same commands from above, starting with:

cd /usr/src/postgresql-7.2.1-1
CYGWIN-PATCHES/build.sh 7.2.1 1

uncompressed, untarred, initialized a new cluster, started the server
created a db, restored the same dump, dropped the db.

Repeat the create/restore/drop sequence 6 times, no crash :)

===============================

Barry

David,

On Sun, May 12, 2002 at 10:24:04AM -0400, David P. Caldwell wrote:
> Maybe we should revise the patch to reflect the current source tree?

Yes.

> I'm
> not at all familiar with protocol in this case, but if you want me to do
> something, let me know.

It is usually best to submit patches against the current CVS -- it
increases the chance that they will be accepted.

> Of course, I suppose I should confirm that my install is working first ...
> :)

Yes! Although, it seems that Barry Pederson has already done the
honors...

Jason

David,

On Sun, May 12, 2002 at 10:21:16AM -0400, David P. Caldwell wrote:
> I was surprised when I examined it ... the script didn't seem to be doing
> anything magical that I wasn't. (Run configure, run make ...)

build.sh is not magic -- it is just how I build Cygwin PostgreSQL.
It is actually meant more to explain how I build than as a script to
use since it implicitly assumes my environment.

> At first, I was unable to use build.sh to build because I didn't have ant
> installed and/or set up. After downloading, setting the JAVA_HOME and
> ANT_HOME variables, and adding ANT_HOME/bin to the path, that worked.

Oops! I need to add this to my README! Which I will in the next
iteration.

> The next problem I ran into had to do with Python. Unfortunately, I never
> solved it (see below), so I don't know exactly what caused it. At the time
> that build.sh was running, it was detecting Python 2.1, correctly.
> (python -V gave "2.1.1" or something). However, there was no
> /usr/include/python2.1, only /usr/include/python2.2, on my system. I tried
> my symlink trick to get it to work, but there are apparently
> incompatibilities between the headers or libraries, because it still blew up
> with undefined something or other (I wish I had saved the error message). I
> downgraded to python2.1 through the installer, but that didn't fix it
> either, then upgraded to 2.2, and that didn't do it either. I gave up at
> that point.

Cygwin PostgreSQL should build against Python 2.2 see the following:

http://sources.redhat.com/ml/cygwin-announce/2002/msg00048.html

Additionally, it was built against Python 2.1.1 in the past too. I'm not
sure why you are having problems.

> Seeing that the build.sh script was rather simple, I decided to return to
> the CVS snapshot I had gotten from postgresql.org. I figured that would be
> superior from an administration point of view anyway, because CVS would make
> it easier for me to deal with patches, etc. I also decided to go with
> minimalist options, so I just ran configure --enable-multibyte --with-java.

Building CVS is the best -- especially it you are going to submit a patch.
After some reflection, I would appreciate if either you or Barry submit
the patch. This is because you can reproduce the problem and hence
prove that the patch fixes it. Would you be willing to submit it?

> I noticed that running build.sh did not exhibit the error I complained about
> in my earlier E-mail (with some yacc error), so it occurred to me to check
> the source for that file in CVS. Sure enough, it had been updated since
> 7.2.1 ... so I think I can report that the current development tree doesn't
> build on Cygwin for that reason. (Having run both builds, I also notice
> that someone has been going through and fixing lots of bison warnings, so
> the error was probably introduced then.) I grabbed the 7.2.1 release from
> CVS instead (somewhat counterintuitively tagged REL7_2_STABLE rather than
> REL7_2_1).

I just did a cvs update and was able to build everything but the JDBC
driver. I did not get any yacc errors. And the JDBC problem *may* be
caused by me doing a make distclean without having my ant environment
set first. I've done this before...

> At that point, I had some readline problems (unresolved symbols), so I
> downgraded my readline to 4.2-3 from 4.2a-1. That didn't work, so I
> re-upgraded to 4.2a-1 and ran make again ... and it worked! No explanation
> for how that happened, though I notice now there are separate libreadline4
> and libreadline5 packages in addition, so maybe there are some complexities
> involved that I don't fully grasp.

Hmm...I don't know why you are having problems with readline too. Note
that I submitted a patch to PostgreSQL CVS that was accepted a while ago
so the source should be good to go regarding readline.

> Finally, I edited my source file, ran make again, and everything is fine.
> Here's the diff:
>
> Index: xlog.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql/src/backend/access/transam/xlog.c,v
> retrieving revision 1.86.2.1
> diff -r1.86.2.1 xlog.c
> 1509c1509
> < #ifndef __BEOS__
> ---
> > #if !defined(__BEOS__) && !defined(__CYGWIN__) && !defined(N_PLAT_NLM)
>
> I added the !defined(N_PLAT_NLM) because that's been added to the source
> tree since 7.2.1, to support NetWare (according to the CVS log message).

Adding "!defined(N_PLAT_NLM)" is good, but generate a unified or context
diff with the "-u" or "-c" option instead. Please submit this patch
to pgsql-patches.

> Anyway, thanks to Barry again for the help, and I hope something from this
> narrative helps someone else at some point. I apologize for not documenting
> the steps better ... I should have been focusing on keeping a log, but I got
> impatient.

No problem -- I have been guilty of the above many times myself. Thanks
for your time.

Jason

Barry,

On Sun, May 12, 2002 at 10:37:11AM -0500, Barry Pederson wrote:
> [snip]
> Repeat the create/restore/drop sequence 6 times, no crash :)

Thanks for the above.

Can either David or you submit the patch? See my previous emails for
the details.

BTW, once the patch is accepted (or at least posted), I will build a new
PostgreSQL 7.2.1 that includes it.

Thanks,
Jason

Jason:

>Cygwin PostgreSQL should build against Python 2.2 see the following:
>
> http://sources.redhat.com/ml/cygwin-announce/2002/msg00048.html
>
>Additionally, it was built against Python 2.1.1 in the past too. I'm not
>sure why you are having problems.

Me neither. :) The patched version of the source that I've built now
doesn't include Python, Perl, or CXX interface. Don't know if this affects
anything below.

>> I grabbed the 7.2.1 release from
>> CVS instead (somewhat counterintuitively tagged REL7_2_STABLE rather than
>> REL7_2_1).

>I just did a cvs update and was able to build everything but the JDBC
>driver.

One other caveat that may be README-worthy is that if you are running JDK
1.4, the script tries to build against the new JDBC 3.0 classes now included
as part of J2SE, and fails (there are a bunch of new methods that aren't
implemented in the driver). I pointed my JAVA_HOME to JDK 1.3 in order to
get it to work.

>I did not get any yacc errors.

As for the other stuff, yeah, I'm not sure. I've had lots of mysterious
occurrences (to me) in the course of the last couple of days (but see
below).

> At that point, I had some readline problems (unresolved symbols), so I
> downgraded my readline to 4.2-3 from 4.2a-1. That didn't work, so I
> re-upgraded to 4.2a-1 and ran make again ... and it worked!

One issue that occurs to me is that I did *not* remove the binary version of
PostgreSQL when building my version. Combined with the fact that /bin is
(duh) in my path, this may have caused all sorts of confusion vis-a-vis
linking, etc. This may explain why uninstalling and reinstalling random
programs (like readline) fixed some of my problems, by causing programs to
be relinked. I now have removed the PostgreSQL package, so things may go
differently (hopefully better) for me if I try to build from the current CVS
tree.

>Adding "!defined(N_PLAT_NLM)" is good, but generate a unified or context
>diff with the "-u" or "-c" option instead. Please submit this patch
>to pgsql-patches.

Lucky for you I just learned about diff last week. Otherwise, I'd be
mystified. :)

>After some reflection, I would appreciate if either you or Barry submit
>the patch. This is because you can reproduce the problem and hence
>prove that the patch fixes it. Would you be willing to submit it?

Well, I'd be willing if Barry's not :). Seriously, it sounds like he's got
an easier reproduction case than mine. I can reproduce the problem at will,
but my case is not something I could submit along with the patch. I've just
run a small test case that worked fine, but I'm not quite to the point of
signing off on it -- my test case took about 30-60 minutes to blow up,
usually.

In addition, I'm a little terrified of disturbing my newly stable system,
since I feel like some luck was involved in getting it built. I'll be
willing to (carefully) mess with it if Barry's not. Barry? Please? :)

-- David.

-----Original Message-----
From: Jason Tishler [mailto:jason(at)tishler(dot)net]
Sent: Sunday, May 12, 2002 4:52 PM
To: David P. Caldwell
Cc: bp(at)barryp(dot)org; pgsql-cygwin(at)postgresql(dot)org
Subject: Re: [CYGWIN] rename() vs. link(); building from source

> The next problem I ran into had to do with Python. Unfortunately, I never
> solved it (see below), so I don't know exactly what caused it. At the
time
> that build.sh was running, it was detecting Python 2.1, correctly.
> (python -V gave "2.1.1" or something). However, there was no
> /usr/include/python2.1, only /usr/include/python2.2, on my system. I
tried
> my symlink trick to get it to work, but there are apparently
> incompatibilities between the headers or libraries, because it still blew
up
> with undefined something or other (I wish I had saved the error message).
I
> downgraded to python2.1 through the installer, but that didn't fix it
> either, then upgraded to 2.2, and that didn't do it either. I gave up at
> that point.

> Seeing that the build.sh script was rather simple, I decided to return to
> the CVS snapshot I had gotten from postgresql.org. I figured that would
be
> superior from an administration point of view anyway, because CVS would
make
> it easier for me to deal with patches, etc. I also decided to go with
> minimalist options, so I just ran
configure --enable-multibyte --with-java.

Building CVS is the best -- especially it you are going to submit a patch.
After some reflection, I would appreciate if either you or Barry submit
the patch. This is because you can reproduce the problem and hence
prove that the patch fixes it. Would you be willing to submit it?

> I noticed that running build.sh did not exhibit the error I complained
about
> in my earlier E-mail (with some yacc error), so it occurred to me to check
> the source for that file in CVS. Sure enough, it had been updated since
> 7.2.1 ... so I think I can report that the current development tree
doesn't
> build on Cygwin for that reason. (Having run both builds, I also notice
> that someone has been going through and fixing lots of bison warnings, so
> the error was probably introduced then.)

No explanation
> for how that happened, though I notice now there are separate libreadline4
> and libreadline5 packages in addition, so maybe there are some
complexities
> involved that I don't fully grasp.

Hmm...I don't know why you are having problems with readline too. Note
that I submitted a patch to PostgreSQL CVS that was accepted a while ago
so the source should be good to go regarding readline.

> Finally, I edited my source file, ran make again, and everything is fine.
> Here's the diff:
>
> Index: xlog.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql/src/backend/access/transam/xlog.c,v
> retrieving revision 1.86.2.1
> diff -r1.86.2.1 xlog.c
> 1509c1509
> < #ifndef __BEOS__
> ---
> > #if !defined(__BEOS__) && !defined(__CYGWIN__) && !defined(N_PLAT_NLM)
>
> I added the !defined(N_PLAT_NLM) because that's been added to the source
> tree since 7.2.1, to support NetWare (according to the CVS log message).

> Anyway, thanks to Barry again for the help, and I hope something from this
> narrative helps someone else at some point. I apologize for not
documenting
> the steps better ... I should have been focusing on keeping a log, but I
got
> impatient.

No problem -- I have been guilty of the above many times myself. Thanks
for your time.

Jason

On Sun, May 12, 2002 at 04:51:56PM -0400, Jason Tishler wrote:
> I just did a cvs update and was able to build everything but the JDBC
> driver. I did not get any yacc errors. And the JDBC problem *may* be
> caused by me doing a make distclean without having my ant environment
> set first. I've done this before...

The above problem was solved by upgrading to ant 1.4.1. Hence, current
PostgreSQL CVS builds cleanly under Cygwin.

For the archives, the error that I got from the old ant version (i.e.,
1.3) was:

make[3]: Entering directory `/home/jt/src/pgsql/build/src/interfaces/jdbc'
/usr/local/ant/bin/ant -buildfile /home/jt/src/pgsql/src/interfaces/jdbc/build.xml all \
-Dmajor=7 -Dminor=3 -Dfullversion=7.3devel -Ddef_pgport=5432 -Denable_debug=no
Buildfile: \home\jt\src\pgsql\src\interfaces\jdbc\build.xml

all:

prepare:

BUILD FAILED

C:\home\jt\src\pgsql\src\interfaces\jdbc\build.xml:157: Could not create task of type: condition. Common solutions are to use taskdef to declare your task, or, if this is an optional task, to put the optional.jar in the lib directory of your ant installation (ANT_HOME).

Jason

Barry,

On Sun, May 12, 2002 at 09:12:46PM -0500, Barry Pederson wrote:
> Jason Tishler wrote:
> >On Sun, May 12, 2002 at 10:37:11AM -0500, Barry Pederson wrote:
> >
> >>[snip]
> >>Repeat the create/restore/drop sequence 6 times, no crash :)
> >
> >Thanks for the above.
> >
> >Can either David or you submit the patch? See my previous emails for
> >the details.
>
> Umm..ok Not sure what details from previous emails you mean, or if I saw
> them. So if you could let me know what I need to do, I'll take a whack at
> it.

I have decided to submit the patch myself -- sorry, for the gyrations.
I generally only submit patches that I create and test myself, but I will
make an exception and just point to David and your work in the archives.
Hopefully, this is acceptable by the core PostgreSQL developers.

> [ subscribe to pgsql-patches and just post the patch along with an
> explanation of what it fixes? or do I have to go whole-hog and do it over
> again with a copy of current source from CVS? :(

Yes, the above is the procedure. But, possibly all you would need to do is
replace postgres.exe from the standard Cygwin PostgreSQL with the one
from the CVS build and test.

> Oh yeah, BTW, I ran "make check" against the patched 7.2.1, and it passed
> all 79 tests on my box, FWIW.

Good.

BTW, you were most likely "lucky." Normally, make check will fail
due to connection refused errors unless you are on a server version
of NT/2000/XP. See the README for more details, if interested.

Thanks,
Jason

David,

On Sun, May 12, 2002 at 05:09:29PM -0400, David P. Caldwell wrote:
> Me neither. :) The patched version of the source that I've built now
> doesn't include Python, Perl, or CXX interface. Don't know if this affects
> anything below.

It won't.

> >I just did a cvs update and was able to build everything but the JDBC
> >driver.
>
> One other caveat that may be README-worthy is that if you are running JDK
> 1.4, the script tries to build against the new JDBC 3.0 classes now included
> as part of J2SE, and fails (there are a bunch of new methods that aren't
> implemented in the driver). I pointed my JAVA_HOME to JDK 1.3 in order to
> get it to work.

OK, noted too.

> One issue that occurs to me is that I did *not* remove the binary version of
> PostgreSQL when building my version. Combined with the fact that /bin is
> (duh) in my path, this may have caused all sorts of confusion vis-a-vis
> linking, etc. This may explain why uninstalling and reinstalling random
> programs (like readline) fixed some of my problems, by causing programs to
> be relinked. I now have removed the PostgreSQL package, so things may go
> differently (hopefully better) for me if I try to build from the current CVS
> tree.

The above is not true. I never remove the current PostgreSQL package
and build PostgreSQL all the time without any problems.

> >After some reflection, I would appreciate if either you or Barry submit
> >the patch. This is because you can reproduce the problem and hence
> >prove that the patch fixes it. Would you be willing to submit it?
>
> Well, I'd be willing if Barry's not :).

See my recent post -- I will submit the patch. Wish me luck... :,)

Thanks,
Jason

>> One issue that occurs to me is that I did *not* remove the binary version
of
>> PostgreSQL when building my version. Combined with the fact that /bin is
>> (duh) in my path, this may have caused all sorts of confusion vis-a-vis
>> linking, etc. This may explain why uninstalling and reinstalling random
>> programs (like readline) fixed some of my problems, by causing programs
to
>> be relinked. I now have removed the PostgreSQL package, so things may go
>> differently (hopefully better) for me if I try to build from the current
CVS
>> tree.

>The above is not true. I never remove the current PostgreSQL package
>and build PostgreSQL all the time without any problems.

Good info. I haven't tried it again (and have gotten rather busy in the
last day or so), but I'll be sure to report to the list when I do.

>See my recent post -- I will submit the patch. Wish me luck... :,)

Yes, good luck!

I have also run my massive data load program since the last time I updated
you and can report that it completed successfully (the previous record was
about 7% before crashing, so I think I can confirm the problem is fixed).

Thanks,
Jason