As I found out recently, ECPG is not thread-safe. This is a problem for us, as 
we really need to be able to use ECPG* in a multi-threaded C application. 
Michael mentioned that Lee is working on fixing these problems, but was not 
sure when it would be complete. 

So, my questions are: 
Lee/anyone, do you have an estimated completion date? 
If not, can we (myself plus a "real" C programmer) help you?

Regards, Philip Yarra.

* Yes, we could use libpq, but ECPG minimises our porting from Informix. 
Rewriting everything to use libpq would be too expensive.


Fri, 28 Mar 2003 11:44:37 +1100
Philip Yarra <philip@utiba.com>
ECPG thread-safety

I have put a mailbox file at:

	ftp://candle.pha.pa.us/pub/postgresql/mypatches

where there is a partial implementation of thread-safe ecpg.  Maybe you
can work with Michael to complete it.

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

Philip Yarra wrote:
> As I found out recently, ECPG is not thread-safe. This is a problem for us, as 
> we really need to be able to use ECPG* in a multi-threaded C application. 
> Michael mentioned that Lee is working on fixing these problems, but was not 
> sure when it would be complete. 
> 
> So, my questions are: 
> Lee/anyone, do you have an estimated completion date? 
> If not, can we (myself plus a "real" C programmer) help you?
> 
> Regards, Philip Yarra.
> 
> * Yes, we could use libpq, but ECPG minimises our porting from Informix. 
> Rewriting everything to use libpq would be too expensive.
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: 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
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073


Thu, 27 Mar 2003 21:00:23 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: ECPG thread-safety
On Fri, 28 Mar 2003 13:00, you wrote:
> I have put a mailbox file at:
>
> 	ftp://candle.pha.pa.us/pub/postgresql/mypatches
>
> where there is a partial implementation of thread-safe ecpg.  Maybe you
> can work with Michael to complete it.

Okay, thanks for that. Have grabbed the file, and started reading. I'll also 
wait to hear from Michael or Lee before going too far on this. 

Everything I have read so far suggests the issue is related to SQLCA itself... 
and that would be consistent with what happens in the backend (data is 
inserted, but threads lock straight after). Can anyone enlighten me further?

Thanks and regards, Philip.


Fri, 28 Mar 2003 17:49:04 +1100
Philip Yarra <philip@utiba.com>
Re: ECPG thread-safety
Philip,

You can find the "patch so far" at:

 http://services.csl.co.uk/postgresql/

along with a libpq thread-safe patch.

The thread referenced by Bruce's email details some of the issues
still to be looked at. The main work is integration with the build
system (testing for and linking in POSIX threads) and testing.

I'm more than happy for you to look at at, I haven't had the time I
hoped to complete this.

Thanks, Lee.

Philip Yarra writes:
 > As I found out recently, ECPG is not thread-safe. This is a problem for us, as 
 > we really need to be able to use ECPG* in a multi-threaded C application. 
 > Michael mentioned that Lee is working on fixing these problems, but was not 
 > sure when it would be complete. 
 > 
 > So, my questions are: 
 > Lee/anyone, do you have an estimated completion date? 
 > If not, can we (myself plus a "real" C programmer) help you?
 > 
 > Regards, Philip Yarra.
 > 
 > * Yes, we could use libpq, but ECPG minimises our porting from Informix. 
 > Rewriting everything to use libpq would be too expensive.
 > 


Fri, 28 Mar 2003 09:37:08 +0000
Lee Kindness <lkindness@csl.co.uk>
ECPG thread-safety

I have the libpq patch in my mailbox that just needs configure thread
testing code.  I will get that in for 7.4.

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

Lee Kindness wrote:
> Philip,
> 
> You can find the "patch so far" at:
> 
>  http://services.csl.co.uk/postgresql/
> 
> along with a libpq thread-safe patch.
> 
> The thread referenced by Bruce's email details some of the issues
> still to be looked at. The main work is integration with the build
> system (testing for and linking in POSIX threads) and testing.
> 
> I'm more than happy for you to look at at, I haven't had the time I
> hoped to complete this.
> 
> Thanks, Lee.
> 
> Philip Yarra writes:
>  > As I found out recently, ECPG is not thread-safe. This is a problem for us, as 
>  > we really need to be able to use ECPG* in a multi-threaded C application. 
>  > Michael mentioned that Lee is working on fixing these problems, but was not 
>  > sure when it would be complete. 
>  > 
>  > So, my questions are: 
>  > Lee/anyone, do you have an estimated completion date? 
>  > If not, can we (myself plus a "real" C programmer) help you?
>  > 
>  > Regards, Philip Yarra.
>  > 
>  > * Yes, we could use libpq, but ECPG minimises our porting from Informix. 
>  > Rewriting everything to use libpq would be too expensive.
>  > 
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073


Fri, 28 Mar 2003 10:54:23 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: ECPG thread-safety


--On Friday, March 28, 2003 10:54:23 -0500 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

>
> I have the libpq patch in my mailbox that just needs configure thread
> testing code.  I will get that in for 7.4.
I can help with the UnixWare threads stuff.  Also, Micheal Meskes now has 
an account
on my UnixWare box.

The threads are native on UW, but you need to invoke the cc -Kpthread 
option.

LER

>
> -------------------------------------------------------------------------
> --
>
> Lee Kindness wrote:
>> Philip,
>>
>> You can find the "patch so far" at:
>>
>>  http://services.csl.co.uk/postgresql/
>>
>> along with a libpq thread-safe patch.
>>
>> The thread referenced by Bruce's email details some of the issues
>> still to be looked at. The main work is integration with the build
>> system (testing for and linking in POSIX threads) and testing.
>>
>> I'm more than happy for you to look at at, I haven't had the time I
>> hoped to complete this.
>>
>> Thanks, Lee.
>>
>> Philip Yarra writes:
>>  > As I found out recently, ECPG is not thread-safe. This is a problem
>>  > for us, as  we really need to be able to use ECPG* in a
>>  > multi-threaded C application.  Michael mentioned that Lee is working
>>  > on fixing these problems, but was not  sure when it would be
>>  > complete.
>>  >
>>  > So, my questions are:
>>  > Lee/anyone, do you have an estimated completion date?
>>  > If not, can we (myself plus a "real" C programmer) help you?
>>  >
>>  > Regards, Philip Yarra.
>>  >
>>  > * Yes, we could use libpq, but ECPG minimises our porting from
>>  > Informix.  Rewriting everything to use libpq would be too expensive.
>>  >
>>
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania
> 19073
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749


Fri, 28 Mar 2003 09:59:12 -0600
Larry Rosenman <ler@lerctr.org>
Re: ECPG thread-safety

Would someone take those patches and hunt around for proper 'configure'
tests?  I can do the configure coding, but I don't know what tests to
make.

	http://services.csl.co.uk/postgresql/


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

Larry Rosenman wrote:
> 
> 
> --On Friday, March 28, 2003 10:54:23 -0500 Bruce Momjian 
> <pgman@candle.pha.pa.us> wrote:
> 
> >
> > I have the libpq patch in my mailbox that just needs configure thread
> > testing code.  I will get that in for 7.4.
> I can help with the UnixWare threads stuff.  Also, Micheal Meskes now has 
> an account
> on my UnixWare box.
> 
> The threads are native on UW, but you need to invoke the cc -Kpthread 
> option.
> 
> LER
> 
> >
> > -------------------------------------------------------------------------
> > --
> >
> > Lee Kindness wrote:
> >> Philip,
> >>
> >> You can find the "patch so far" at:
> >>
> >>  http://services.csl.co.uk/postgresql/
> >>
> >> along with a libpq thread-safe patch.
> >>
> >> The thread referenced by Bruce's email details some of the issues
> >> still to be looked at. The main work is integration with the build
> >> system (testing for and linking in POSIX threads) and testing.
> >>
> >> I'm more than happy for you to look at at, I haven't had the time I
> >> hoped to complete this.
> >>
> >> Thanks, Lee.
> >>
> >> Philip Yarra writes:
> >>  > As I found out recently, ECPG is not thread-safe. This is a problem
> >>  > for us, as  we really need to be able to use ECPG* in a
> >>  > multi-threaded C application.  Michael mentioned that Lee is working
> >>  > on fixing these problems, but was not  sure when it would be
> >>  > complete.
> >>  >
> >>  > So, my questions are:
> >>  > Lee/anyone, do you have an estimated completion date?
> >>  > If not, can we (myself plus a "real" C programmer) help you?
> >>  >
> >>  > Regards, Philip Yarra.
> >>  >
> >>  > * Yes, we could use libpq, but ECPG minimises our porting from
> >>  > Informix.  Rewriting everything to use libpq would be too expensive.
> >>  >
> >>
> >
> > --
> >   Bruce Momjian                        |  http://candle.pha.pa.us
> >   pgman@candle.pha.pa.us               |  (610) 359-1001
> >   +  If your life is a hard drive,     |  13 Roberts Road
> >   +  Christ can be your backup.        |  Newtown Square, Pennsylvania
> > 19073
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
> 
> 
> 
> -- 
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
> US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
> 
> 
> 
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073


Fri, 28 Mar 2003 11:00:47 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: ECPG thread-safety


--On Friday, March 28, 2003 11:00:47 -0500 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

>
> Would someone take those patches and hunt around for proper 'configure'
> tests?  I can do the configure coding, but I don't know what tests to
> make.
>
> 	http://services.csl.co.uk/postgresql/
I do know there are configure tests built for UnixWare's pthreads, but I 
don't know where.  I have seen them invoked as I've compiled stuff.

Also, once you compile a piece with -Kpthread you must compile ALL of it 
with -Kpthread.

You are welcome to read the UnixWare docs at http://www.lerctr.org:8458/ or 
on the SCO site.


>
>
> -------------------------------------------------------------------------
> --
>
> Larry Rosenman wrote:
>>
>>
>> --On Friday, March 28, 2003 10:54:23 -0500 Bruce Momjian
>> <pgman@candle.pha.pa.us> wrote:
>>
>> >
>> > I have the libpq patch in my mailbox that just needs configure thread
>> > testing code.  I will get that in for 7.4.
>> I can help with the UnixWare threads stuff.  Also, Micheal Meskes now
>> has  an account
>> on my UnixWare box.
>>
>> The threads are native on UW, but you need to invoke the cc -Kpthread
>> option.
>>
>> LER
>>
>> >
>> > ----------------------------------------------------------------------
>> > --- --
>> >
>> > Lee Kindness wrote:
>> >> Philip,
>> >>
>> >> You can find the "patch so far" at:
>> >>
>> >>  http://services.csl.co.uk/postgresql/
>> >>
>> >> along with a libpq thread-safe patch.
>> >>
>> >> The thread referenced by Bruce's email details some of the issues
>> >> still to be looked at. The main work is integration with the build
>> >> system (testing for and linking in POSIX threads) and testing.
>> >>
>> >> I'm more than happy for you to look at at, I haven't had the time I
>> >> hoped to complete this.
>> >>
>> >> Thanks, Lee.
>> >>
>> >> Philip Yarra writes:
>> >>  > As I found out recently, ECPG is not thread-safe. This is a problem
>> >>  > for us, as  we really need to be able to use ECPG* in a
>> >>  > multi-threaded C application.  Michael mentioned that Lee is
>> >>  > working on fixing these problems, but was not  sure when it would
>> >>  > be complete.
>> >>  >
>> >>  > So, my questions are:
>> >>  > Lee/anyone, do you have an estimated completion date?
>> >>  > If not, can we (myself plus a "real" C programmer) help you?
>> >>  >
>> >>  > Regards, Philip Yarra.
>> >>  >
>> >>  > * Yes, we could use libpq, but ECPG minimises our porting from
>> >>  > Informix.  Rewriting everything to use libpq would be too
>> >>  > expensive.
>> >>  >
>> >>
>> >
>> > --
>> >   Bruce Momjian                        |  http://candle.pha.pa.us
>> >   pgman@candle.pha.pa.us               |  (610) 359-1001
>> >   +  If your life is a hard drive,     |  13 Roberts Road
>> >   +  Christ can be your backup.        |  Newtown Square, Pennsylvania
>> > 19073
>> >
>> >
>> > ---------------------------(end of
>> > broadcast)--------------------------- TIP 6: Have you searched our
>> > list archives?
>> >
>> > http://archives.postgresql.org
>> >
>>
>>
>>
>> --
>> Larry Rosenman                     http://www.lerctr.org/~ler
>> Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
>> US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
>>
>>
>>
>>
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania
> 19073



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749


Fri, 28 Mar 2003 10:10:34 -0600
Larry Rosenman <ler@lerctr.org>
Re: ECPG thread-safety
I must have spent at least a day looking at configure threads tests
the past few months. Look at the tests in Python, OpenLDAP, MySQL,
Apache 2.0, Perl, ... each and everyone of them is different!
Ouch. Way above my experience in configure.

One of the packages (sorry cannot find my notes on which one!) I
looked at down the test on a per-OS level - supplying the tread
compile and link flags used on that OS and CC to see if they
worked... Probably the simplest way to go?

L.

Bruce Momjian writes:
 > 
 > Would someone take those patches and hunt around for proper 'configure'
 > tests?  I can do the configure coding, but I don't know what tests to
 > make.
 > 
 > 	http://services.csl.co.uk/postgresql/
 > 
 > 
 > ---------------------------------------------------------------------------
 > 
 > Larry Rosenman wrote:
 > > 
 > > 
 > > --On Friday, March 28, 2003 10:54:23 -0500 Bruce Momjian 
 > > <pgman@candle.pha.pa.us> wrote:
 > > 
 > > >
 > > > I have the libpq patch in my mailbox that just needs configure thread
 > > > testing code.  I will get that in for 7.4.
 > > I can help with the UnixWare threads stuff.  Also, Micheal Meskes now has 
 > > an account
 > > on my UnixWare box.
 > > 
 > > The threads are native on UW, but you need to invoke the cc -Kpthread 
 > > option.
 > > 
 > > LER
 > > 
 > > >
 > > > -------------------------------------------------------------------------
 > > > --
 > > >
 > > > Lee Kindness wrote:
 > > >> Philip,
 > > >>
 > > >> You can find the "patch so far" at:
 > > >>
 > > >>  http://services.csl.co.uk/postgresql/
 > > >>
 > > >> along with a libpq thread-safe patch.
 > > >>
 > > >> The thread referenced by Bruce's email details some of the issues
 > > >> still to be looked at. The main work is integration with the build
 > > >> system (testing for and linking in POSIX threads) and testing.
 > > >>
 > > >> I'm more than happy for you to look at at, I haven't had the time I
 > > >> hoped to complete this.
 > > >>
 > > >> Thanks, Lee.
 > > >>
 > > >> Philip Yarra writes:
 > > >>  > As I found out recently, ECPG is not thread-safe. This is a problem
 > > >>  > for us, as  we really need to be able to use ECPG* in a
 > > >>  > multi-threaded C application.  Michael mentioned that Lee is working
 > > >>  > on fixing these problems, but was not  sure when it would be
 > > >>  > complete.
 > > >>  >
 > > >>  > So, my questions are:
 > > >>  > Lee/anyone, do you have an estimated completion date?
 > > >>  > If not, can we (myself plus a "real" C programmer) help you?
 > > >>  >
 > > >>  > Regards, Philip Yarra.
 > > >>  >
 > > >>  > * Yes, we could use libpq, but ECPG minimises our porting from
 > > >>  > Informix.  Rewriting everything to use libpq would be too expensive.
 > > >>  >
 > > >>
 > > >
 > > > --
 > > >   Bruce Momjian                        |  http://candle.pha.pa.us
 > > >   pgman@candle.pha.pa.us               |  (610) 359-1001
 > > >   +  If your life is a hard drive,     |  13 Roberts Road
 > > >   +  Christ can be your backup.        |  Newtown Square, Pennsylvania
 > > > 19073
 > > >
 > > >
 > > > ---------------------------(end of broadcast)---------------------------
 > > > TIP 6: Have you searched our list archives?
 > > >
 > > > http://archives.postgresql.org
 > > >
 > > 
 > > 
 > > 
 > > -- 
 > > Larry Rosenman                     http://www.lerctr.org/~ler
 > > Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
 > > US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
 > > 
 > > 
 > > 
 > > 
 > 
 > -- 
 >   Bruce Momjian                        |  http://candle.pha.pa.us
 >   pgman@candle.pha.pa.us               |  (610) 359-1001
 >   +  If your life is a hard drive,     |  13 Roberts Road
 >   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073


Fri, 28 Mar 2003 16:15:08 +0000
Lee Kindness <lkindness@csl.co.uk>
Re: ECPG thread-safety
On Friday 28 March 2003 21:30, you wrote:
> Would someone take those patches and hunt around for proper 'configure'
> tests?  I can do the configure coding, but I don't know what tests to
> make.
>
> 	http://services.csl.co.uk/postgresql/

I also need configure tests for thread for one of my other application and 
don't know how to put them. So I have left those as additional ldflags 
options to users.

I suggest we somehow test following config to start with

1) Linuxthreads on linux
Threads are usually installed in /usr/ So pthread.h and -lpthread should work 
on most setups.

2) Native freeBSD threads
pthread.h in /usr/include and lc_r

3)linuxthreads on freeBSD, ports collection
/usr/local/include/pthreads/linuxthreads/pthread.h
/usr/local/lib/libpthread.so

For testing the library, I think it is enough to init an thread attr. like 
pthread_init_attr, that should be enough to test header and library.

I don't how we are going to let people specify thread implementation where 
there are multiple thread libraries are available .e.g. freeBSD.

HTH

 Shridhar


Fri, 28 Mar 2003 21:45:53 +0530
Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Re: ECPG thread-safety
On Friday 28 March 2003 21:45, you wrote:
> For testing the library, I think it is enough to init an thread attr. like
> pthread_init_attr, that should be enough to test header and library.

And compiler flags, I forgot.. -pthread on freeBSD/gcc and -D_REENTRANT on 
linux at least. FreeBSD needs _THREAD_SAFE as well IIRC.

 Shridhar


Fri, 28 Mar 2003 22:26:20 +0530
Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Re: ECPG thread-safety

Yep.  I need someone who knows these OS's to get some tests together.

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

Shridhar Daithankar wrote:
> On Friday 28 March 2003 21:45, you wrote:
> > For testing the library, I think it is enough to init an thread attr. like
> > pthread_init_attr, that should be enough to test header and library.
> 
> And compiler flags, I forgot.. -pthread on freeBSD/gcc and -D_REENTRANT on 
> linux at least. FreeBSD needs _THREAD_SAFE as well IIRC.
> 
>  Shridhar
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073


Fri, 28 Mar 2003 12:04:00 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: ECPG thread-safety
On Fri, Mar 28, 2003 at 05:49:04PM +1100, Philip Yarra wrote:
> Okay, thanks for that. Have grabbed the file, and started reading. I'll also 
> wait to hear from Michael or Lee before going too far on this. 

Don't be surprised if I'm a bit late in answering emails on the list.
I'm currently very busy.

I'd be interested to get ecpg thread safe. 

Is this the only problem you're facing with Informix? I'm currently
working on other Informix compatibility stuff. And I'd like to get that
tested as good as possible.

Michael
-- 
Michael Meskes
Email: Michael@Fam-Meskes.De
ICQ: 179140304
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


Sun, 30 Mar 2003 16:06:05 +0200
Michael Meskes <meskes@postgresql.org>
Re: ECPG thread-safety
On Mon, 31 Mar 2003 00:06, Michael Meskes wrote:
> Is this the only problem you're facing with Informix? I'm currently
> working on other Informix compatibility stuff. And I'd like to get that
> tested as good as possible.

Yes, I recall reading that you were working on better Informix compatibility - 
most welcome! Honestly, the changes we needed to make to port from Informix 
were pretty minor, as I recall: 
- some of the connection syntax differred
- figuring out that OID was not populated in sqlca if not auto-committing 
(makes sense really)
- our original code used non-standard ways to name a PREPAREd statement which 
threw ECPG (and according the Informix doco shouldn't really have worked for 
that either!) so I fixed that in both development streams

You can probably deduce from this that we are not really using a great deal of 
functionality in this app - what we have ported so far is a simple logging 
server. We really won't be porting any more until ECPG is thread-safe. It's a 
major show-stopper, since all of our apps are built on the same (pthreads) 
framework.

That said, we would love to help test further Informix compatibility stuff - 
anything that makes our future porting process easier would be welcome! Let 
us know what you'd like us to test. Diffs are fine.

Regards, Philip.


Mon, 31 Mar 2003 11:23:04 +1100
Philip Yarra <philip@utiba.com>
Re: ECPG thread-safety
On Mon, Mar 31, 2003 at 11:23:04AM +1100, Philip Yarra wrote:
> That said, we would love to help test further Informix compatibility stuff - 
> anything that makes our future porting process easier would be welcome! Let 
> us know what you'd like us to test. Diffs are fine.

Can you take ecpg from CVS? I will not be able to answer email for about
a two week long vacation trip, but everything I've done so far is in
CVS.

Michael
-- 
Michael Meskes
Email: Michael@Fam-Meskes.De
ICQ: 179140304
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


Thu, 10 Apr 2003 19:20:04 +0200
Michael Meskes <meskes@postgresql.org>
Re: ECPG thread-safety
On Fri, 11 Apr 2003 03:20, Michael Meskes wrote:
> Can you take ecpg from CVS? I will not be able to answer email for about
> a two week long vacation trip, but everything I've done so far is in
> CVS.

Hi Michael, I grabbed everything from CVS and tried building, but ran into a 
few problems.

Bison 1.35 and 1.50 both have bugs that prevent successful compilation, so I 
moved to 1.85. This appears to work okay. Is there some way during configure 
to check for broken bison versions and complain loudly?

Once I compiled the source tree, and got it installed, I ran into further 
problems as soon as I tried to link against the ecpg libs:

$ gcc -I/usr/local/pgsql/include -L/usr/local/pgsql/lib -lecpg test.c
/usr/local/pgsql/lib/libecpg.so: undefined reference to 
`PGTYPESnumeric_from_asc'
/usr/local/pgsql/lib/libecpg.so: undefined reference to `PGTYPESdate_to_asc'
/usr/local/pgsql/lib/libecpg.so: undefined reference to 
`PGTYPESinterval_from_asc'
/usr/local/pgsql/lib/libecpg.so: undefined reference to 
`PGTYPESinterval_to_asc'
/usr/local/pgsql/lib/libecpg.so: undefined reference to 
`PGTYPEStimestamp_from_asc'
/usr/local/pgsql/lib/libecpg.so: undefined reference to `PGTYPESdate_from_asc'
/usr/local/pgsql/lib/libecpg.so: undefined reference to `PGTYPESnumeric_copy'
/usr/local/pgsql/lib/libecpg.so: undefined reference to `PGTYPESinterval_copy'
/usr/local/pgsql/lib/libecpg.so: undefined reference to 
`PGTYPEStimestamp_to_asc'
/usr/local/pgsql/lib/libecpg.so: undefined reference to 
`PGTYPESnumeric_to_asc'
collect2: ld returned 1 exit status

Is there something obvious I am doing wrong here? Is there something borked in 
my build environment? I've attached my test.pgc.

Regards, Philip Yarra.
Tue, 22 Apr 2003 13:45:40 +1000
Philip Yarra <philip@utiba.com>
Re: ECPG CVS version problems
On Tue, 22 Apr 2003 13:45, Philip Yarra wrote:
> Bison 1.35 and 1.50 both have bugs that prevent successful compilation, so
> I moved to 1.85. 

Correction, bison 1.875. Sorry about that, folks.

Philip.


Tue, 22 Apr 2003 14:02:16 +1000
Philip Yarra <philip@utiba.com>
Re: ECPG CVS version problems
On Fri, 28 Mar 2003 17:49, Philip Yarra wrote:
> On Fri, 28 Mar 2003 13:00, you wrote:
> > I have put a mailbox file at:
> >
> > 	ftp://candle.pha.pa.us/pub/postgresql/mypatches
> >
> > where there is a partial implementation of thread-safe ecpg.  Maybe you
> > can work with Michael to complete it.
>
> Okay, thanks for that. Have grabbed the file, and started reading. I'll
> also wait to hear from Michael or Lee before going too far on this.

I've had a few tries at testing the ECPG threadsafe patch, but so far no luck, 
probably due to my own lack of experience. Can someone help me out with how 
to test this? 

So far I have:
- run configure
- applied Lee's patch to the source tree for 7.3.2
- edited src/Makefile.global, adding -pthread to CFLAGS and and -lpthread to 
LIBS
- make and make install
- make our own pthread'd app, linking against newly installed pgsql
Then when I run our app with 3 DB threads, I can watch 2 of the threads fail 
to return from EXEC SQL, which is exactly the same behaviour we used to get.

Can anyone point me in the right direction? I'm building on RedHat Linux 7.3 
on Intel, using all standard tools for that version (except updated bison 
from 1.35 to 1.875). So gcc 2.96, gmake 3.79.1, etc. Let me know if more 
details are required.

Regards, Philip Yarra.


Tue, 22 Apr 2003 14:05:33 +1000
Philip Yarra <philip@utiba.com>
Re: ECPG thread-safety
Philip Yarra writes:
 > I've had a few tries at testing the ECPG threadsafe patch, but so
 > far no luck, probably due to my own lack of experience. Can someone
 > help me out with how to test this?
 > 
 > So far I have:
 > - run configure
 > - applied Lee's patch to the source tree for 7.3.2
 > - edited src/Makefile.global, adding -pthread to CFLAGS and and
 > -lpthread to LIBS
 > - make and make install
 > - make our own pthread'd app, linking against newly installed pgsql
 > Then when I run our app with 3 DB threads, I can watch 2 of the threads fai=
 > l=20
 > to return from EXEC SQL, which is exactly the same behaviour we used to get.
 > 
 > Can anyone point me in the right direction? I'm building on RedHat Linux 7.=
 > 3=20
 > on Intel, using all standard tools for that version (except updated bison=
 > =20
 > from 1.35 to 1.875). So gcc 2.96, gmake 3.79.1, etc. Let me know if more=20
 > details are required.

Even with this patch you'll still be limited by the underlying
libpq. So for example you cannot share a connection between threads
without implementing locking to prevent multiple access to that
connection.

I guess the best way would be to open a named connection for EACH
thread. This SHOULD work, but again not tested...

L.


Wed, 23 Apr 2003 09:47:06 +0100
Lee Kindness <lkindness@csl.co.uk>
ECPG thread-safety

I have libpq thread-safe patch in my queue:

	http://momjian.postgresql.org/cgi-bin/pgpatches

Once I have a way to test thread flags for various OS's, I will apply
it.  Maybe you guys can help with that too.

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

Lee Kindness wrote:
> Philip Yarra writes:
>  > I've had a few tries at testing the ECPG threadsafe patch, but so
>  > far no luck, probably due to my own lack of experience. Can someone
>  > help me out with how to test this?
>  > 
>  > So far I have:
>  > - run configure
>  > - applied Lee's patch to the source tree for 7.3.2
>  > - edited src/Makefile.global, adding -pthread to CFLAGS and and
>  > -lpthread to LIBS
>  > - make and make install
>  > - make our own pthread'd app, linking against newly installed pgsql
>  > Then when I run our app with 3 DB threads, I can watch 2 of the threads fai=
>  > l=20
>  > to return from EXEC SQL, which is exactly the same behaviour we used to get.
>  > 
>  > Can anyone point me in the right direction? I'm building on RedHat Linux 7.=
>  > 3=20
>  > on Intel, using all standard tools for that version (except updated bison=
>  > =20
>  > from 1.35 to 1.875). So gcc 2.96, gmake 3.79.1, etc. Let me know if more=20
>  > details are required.
> 
> Even with this patch you'll still be limited by the underlying
> libpq. So for example you cannot share a connection between threads
> without implementing locking to prevent multiple access to that
> connection.
> 
> I guess the best way would be to open a named connection for EACH
> thread. This SHOULD work, but again not tested...
> 
> L.
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: 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
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073


Wed, 23 Apr 2003 14:15:59 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: ECPG thread-safety
On Wed, 23 Apr 2003 18:47, Lee Kindness wrote:
> Even with this patch you'll still be limited by the underlying
> libpq. So for example you cannot share a connection between threads
> without implementing locking to prevent multiple access to that
> connection.

Oh yes, I figured that. Each thread in this application opens its own 
connection, so this ought not to be the issue. Each DB insert actually gets 
the data into the table, but 2 of the 3 threads stop after that... possibly 
due to concurrently accessing sections of the sqlca struct? (that's just a 
guess though)

Our code is a bit tricky to get running - I might see if I can create a simple 
test harness to duplicate the problem and post it to you.

Regards, Philip.


Thu, 24 Apr 2003 10:17:15 +1000
Philip Yarra <philip@utiba.com>
Re: ECPG thread-safety
On Thu, 24 Apr 2003 04:15, Bruce Momjian wrote:
> I have libpq thread-safe patch in my queue:
> Once I have a way to test thread flags for various OS's, I will apply
> it.  Maybe you guys can help with that too.

Happy to help. We have various Linux flavours plus Tru64 Unix (OSF1 v4.0) that 
we can test on.

Regards, Philip.


Thu, 24 Apr 2003 10:24:25 +1000
Philip Yarra <philip@utiba.com>
Re: ECPG thread-safety

Michael, I have the ecpg thread stuff in the patches queue:

	http://momjian.postgresql.org/cgi-bin/pgpatches

I need you to look at that and integrate it into ecpg soon so we can get
some testing before we hit 7.4 beta.

As far as the thread flags, I think we are going to just have to use a
HAVE_THREADS configure define, and then fill it in for every OS with
OS-specific tests.  I can do that part if you code with HAVE_THREADS.

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

Michael Meskes wrote:
> On Fri, Mar 28, 2003 at 05:49:04PM +1100, Philip Yarra wrote:
> > Okay, thanks for that. Have grabbed the file, and started reading. I'll also 
> > wait to hear from Michael or Lee before going too far on this. 
> 
> Don't be surprised if I'm a bit late in answering emails on the list.
> I'm currently very busy.
> 
> I'd be interested to get ecpg thread safe. 
> 
> Is this the only problem you're facing with Informix? I'm currently
> working on other Informix compatibility stuff. And I'd like to get that
> tested as good as possible.
> 
> Michael
> -- 
> Michael Meskes
> Email: Michael@Fam-Meskes.De
> ICQ: 179140304
> Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/docs/faqs/FAQ.html
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 26 May 2003 01:09:44 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: ECPG thread-safety
I have developed the following configure thread test based on your
information.  I have opted for a simple check for pthread.h, and we can
then fill in any additional library flags needed for various OS's.

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

Shridhar Daithankar wrote:
> On Friday 28 March 2003 21:30, you wrote:
> > Would someone take those patches and hunt around for proper 'configure'
> > tests?  I can do the configure coding, but I don't know what tests to
> > make.
> >
> > 	http://services.csl.co.uk/postgresql/
> 
> I also need configure tests for thread for one of my other application and 
> don't know how to put them. So I have left those as additional ldflags 
> options to users.
> 
> I suggest we somehow test following config to start with
> 
> 1) Linuxthreads on linux
> Threads are usually installed in /usr/ So pthread.h and -lpthread should work 
> on most setups.
> 
> 2) Native freeBSD threads
> pthread.h in /usr/include and lc_r
> 
> 3)linuxthreads on freeBSD, ports collection
> /usr/local/include/pthreads/linuxthreads/pthread.h
> /usr/local/lib/libpthread.so
> 
> For testing the library, I think it is enough to init an thread attr. like 
> pthread_init_attr, that should be enough to test header and library.
> 
> I don't how we are going to let people specify thread implementation where 
> there are multiple thread libraries are available .e.g. freeBSD.
> 
> HTH
> 
>  Shridhar
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.253
diff -c -c -r1.253 configure.in
*** configure.in	22 May 2003 16:39:28 -0000	1.253
--- configure.in	26 May 2003 16:57:51 -0000
***************
*** 506,511 ****
--- 506,514 ----
                [  --without-zlib          do not use Zlib])
  
  
+ #
+ # Elf
+ #
  
  # Assume system is ELF if it predefines __ELF__ as 1,
  # otherwise believe host_os based default.
***************
*** 527,533 ****
--- 530,557 ----
  fi])
  AC_SUBST(ELF_SYS)
  
+ #
+ # Pthreads
+ #
  
+ AC_CHECK_HEADER(pthread.h,
+ 	[AC_DEFINE(HAVE_THREADS, 1, [Define to 1 if you have the threads interface.])])
+ if test ! -z "$HAVE_THREADS"
+ then	
+ 	case $host_os in
+ 		# BSD/OS and NetBSD require no special libraries
+ 		netbsd*|bsdi*) THREAD_LIBS="" ;;
+ 		freebsd*) THREAD_LIBS="-lc_r" ;;
+ 		linux*) THREAD_LIBS="-lpthread" ;;
+ 	# other operating systems might fail because they have pthread.h but need
+ 	# special libs we don't know about yet.
+ 	esac
+ fi
+ AC_SUBST(THREAD_LIBS)
+ 
+ #
+ # Assignments
+ #
  
  CPPFLAGS="$CPPFLAGS $INCLUDES"
  LDFLAGS="$LDFLAGS $LIBDIRS"
Index: src/Makefile.global.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/Makefile.global.in,v
retrieving revision 1.162
diff -c -c -r1.162 Makefile.global.in
*** src/Makefile.global.in	11 May 2003 20:50:53 -0000	1.162
--- src/Makefile.global.in	26 May 2003 16:57:53 -0000
***************
*** 152,157 ****
--- 152,159 ----
  TK_LIB_SPEC		= @TK_LIB_SPEC@
  TK_XINCLUDES		= @TK_XINCLUDES@
  
+ THREAD_LIBS		= @THREAD_LIBS@
+ 
  have_docbook	= @have_docbook@
  DOCBOOKSTYLE	= @DOCBOOKSTYLE@
  COLLATEINDEX	= @COLLATEINDEX@
Index: src/include/pg_config.h.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/pg_config.h.in,v
retrieving revision 1.47
diff -c -c -r1.47 pg_config.h.in
*** src/include/pg_config.h.in	22 May 2003 16:39:30 -0000	1.47
--- src/include/pg_config.h.in	26 May 2003 16:57:57 -0000
***************
*** 465,470 ****
--- 465,473 ----
  /* Define to 1 if you have the <termios.h> header file. */
  #undef HAVE_TERMIOS_H
  
+ /* Define to 1 if you have the <pthread.h> header file. */
+ #undef HAVE_THREADS
+ 
  /* Define to 1 if your `struct tm' has `tm_zone'. Deprecated, use
     `HAVE_STRUCT_TM_TM_ZONE' instead. */
  #undef HAVE_TM_ZONE
Mon, 26 May 2003 13:01:49 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] ECPG thread-safety
Shridhar Daithankar wrote:
> On Friday 28 March 2003 21:45, you wrote:
> > For testing the library, I think it is enough to init an thread attr. like
> > pthread_init_attr, that should be enough to test header and library.
> 
> And compiler flags, I forgot.. -pthread on freeBSD/gcc and -D_REENTRANT on 
> linux at least. FreeBSD needs _THREAD_SAFE as well IIRC.

Are you saying FreeBSD actually has a -pthread compiler flag?  And Linux
needs REENTRANT.  We can do that.  Here is an updated patch.  Of course,
I need to run autoconf too.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.253
diff -c -c -r1.253 configure.in
*** configure.in	22 May 2003 16:39:28 -0000	1.253
--- configure.in	26 May 2003 17:05:52 -0000
***************
*** 506,511 ****
--- 506,514 ----
                [  --without-zlib          do not use Zlib])
  
  
+ #
+ # Elf
+ #
  
  # Assume system is ELF if it predefines __ELF__ as 1,
  # otherwise believe host_os based default.
***************
*** 527,533 ****
--- 530,560 ----
  fi])
  AC_SUBST(ELF_SYS)
  
+ #
+ # Pthreads
+ #
  
+ AC_CHECK_HEADER(pthread.h,
+ 	[AC_DEFINE(HAVE_THREADS, 1, [Define to 1 if you have the threads interface.])])
+ if test ! -z "$HAVE_THREADS"
+ then	
+ 	case $host_os in
+ 		# BSD/OS and NetBSD require no special libraries or flags
+ 		netbsd*|bsdi*) ;;
+ 		freebsd*) THREAD_LIBS="-lc_r"
+ 			  THREAD_CFLAGS="-pthread" ;;
+ 		linux*) THREAD_LIBS="-lpthread"
+ 			THREAD_CFLAGS="-D_REENTRANT" ;;
+ 	# other operating systems might fail because they have pthread.h but need
+ 	# special libs we don't know about yet.
+ 	esac
+ fi
+ AC_SUBST(THREAD_LIBS)
+ AC_SUBST(THREAD_CFLAGS)
+ 
+ #
+ # Assignments
+ #
  
  CPPFLAGS="$CPPFLAGS $INCLUDES"
  LDFLAGS="$LDFLAGS $LIBDIRS"
Index: src/Makefile.global.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/Makefile.global.in,v
retrieving revision 1.162
diff -c -c -r1.162 Makefile.global.in
*** src/Makefile.global.in	11 May 2003 20:50:53 -0000	1.162
--- src/Makefile.global.in	26 May 2003 17:05:54 -0000
***************
*** 152,157 ****
--- 152,160 ----
  TK_LIB_SPEC		= @TK_LIB_SPEC@
  TK_XINCLUDES		= @TK_XINCLUDES@
  
+ THREAD_CFLAGS		= @THREAD_CFLAGS@
+ THREAD_LIBS		= @THREAD_LIBS@
+ 
  have_docbook	= @have_docbook@
  DOCBOOKSTYLE	= @DOCBOOKSTYLE@
  COLLATEINDEX	= @COLLATEINDEX@
Index: src/include/pg_config.h.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/pg_config.h.in,v
retrieving revision 1.47
diff -c -c -r1.47 pg_config.h.in
*** src/include/pg_config.h.in	22 May 2003 16:39:30 -0000	1.47
--- src/include/pg_config.h.in	26 May 2003 17:05:56 -0000
***************
*** 465,470 ****
--- 465,473 ----
  /* Define to 1 if you have the <termios.h> header file. */
  #undef HAVE_TERMIOS_H
  
+ /* Define to 1 if you have the <pthread.h> header file. */
+ #undef HAVE_THREADS
+ 
  /* Define to 1 if your `struct tm' has `tm_zone'. Deprecated, use
     `HAVE_STRUCT_TM_TM_ZONE' instead. */
  #undef HAVE_TM_ZONE
Mon, 26 May 2003 13:06:36 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] ECPG thread-safety
On Mon, 2003-05-26 at 13:06, Bruce Momjian wrote:
> Shridhar Daithankar wrote:
> > On Friday 28 March 2003 21:45, you wrote:
> > > For testing the library, I think it is enough to init an thread attr. like
> > > pthread_init_attr, that should be enough to test header and library.
> > 
> > And compiler flags, I forgot.. -pthread on freeBSD/gcc and -D_REENTRANT on 
> > linux at least. FreeBSD needs _THREAD_SAFE as well IIRC.
> 
> Are you saying FreeBSD actually has a -pthread compiler flag?  And Linux
> needs REENTRANT.  We can do that.  Here is an updated patch.  Of course,
> I need to run autoconf too.

If I'm not mistaken, you use -lpthread on FreeBSD 4.x, and -lc_r on
FreeBSD 5.x.

-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
26 May 2003 13:32:03 -0400
Rod Taylor <rbt@rbt.ca>
Re: [HACKERS] ECPG thread-safety
Rod Taylor wrote:
-- Start of PGP signed section.
> On Mon, 2003-05-26 at 13:06, Bruce Momjian wrote:
> > Shridhar Daithankar wrote:
> > > On Friday 28 March 2003 21:45, you wrote:
> > > > For testing the library, I think it is enough to init an thread attr. like
> > > > pthread_init_attr, that should be enough to test header and library.
> > > 
> > > And compiler flags, I forgot.. -pthread on freeBSD/gcc and -D_REENTRANT on 
> > > linux at least. FreeBSD needs _THREAD_SAFE as well IIRC.
> > 
> > Are you saying FreeBSD actually has a -pthread compiler flag?  And Linux
> > needs REENTRANT.  We can do that.  Here is an updated patch.  Of course,
> > I need to run autoconf too.
> 
> If I'm not mistaken, you use -lpthread on FreeBSD 4.x, and -lc_r on
> FreeBSD 5.x.

Thanks.  Patch updated and attached.  Are there any FreeBSD 3.X machines
still around that have pthread.h?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.253
diff -c -c -r1.253 configure.in
*** configure.in	22 May 2003 16:39:28 -0000	1.253
--- configure.in	26 May 2003 17:38:28 -0000
***************
*** 506,511 ****
--- 506,514 ----
                [  --without-zlib          do not use Zlib])
  
  
+ #
+ # Elf
+ #
  
  # Assume system is ELF if it predefines __ELF__ as 1,
  # otherwise believe host_os based default.
***************
*** 527,533 ****
--- 530,560 ----
  fi])
  AC_SUBST(ELF_SYS)
  
+ #
+ # Pthreads
+ #
  
+ AC_CHECK_HEADER(pthread.h,
+ 	[AC_DEFINE(HAVE_THREADS, 1, [Define to 1 if you have the threads interface.])])
+ if test ! -z "$HAVE_THREADS"
+ then	
+ 	case $host_os in
+ 		# BSD/OS and NetBSD require no special libraries or flags
+ 		netbsd*|bsdi*) ;;
+ 		freebsd4*) THREAD_CFLAGS="-pthread" ;;
+ 		freebsd*) THREAD_LIBS="-lc_r" ;;
+ 		linux*) THREAD_LIBS="-lpthread"
+ 			THREAD_CFLAGS="-D_REENTRANT" ;;
+ 	# other operating systems might fail because they have pthread.h but need
+ 	# special libs we don't know about yet.
+ 	esac
+ fi
+ AC_SUBST(THREAD_LIBS)
+ AC_SUBST(THREAD_CFLAGS)
+ 
+ #
+ # Assignments
+ #
  
  CPPFLAGS="$CPPFLAGS $INCLUDES"
  LDFLAGS="$LDFLAGS $LIBDIRS"
Index: src/Makefile.global.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/Makefile.global.in,v
retrieving revision 1.162
diff -c -c -r1.162 Makefile.global.in
*** src/Makefile.global.in	11 May 2003 20:50:53 -0000	1.162
--- src/Makefile.global.in	26 May 2003 17:38:31 -0000
***************
*** 152,157 ****
--- 152,160 ----
  TK_LIB_SPEC		= @TK_LIB_SPEC@
  TK_XINCLUDES		= @TK_XINCLUDES@
  
+ THREAD_CFLAGS		= @THREAD_CFLAGS@
+ THREAD_LIBS		= @THREAD_LIBS@
+ 
  have_docbook	= @have_docbook@
  DOCBOOKSTYLE	= @DOCBOOKSTYLE@
  COLLATEINDEX	= @COLLATEINDEX@
Index: src/include/pg_config.h.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/pg_config.h.in,v
retrieving revision 1.47
diff -c -c -r1.47 pg_config.h.in
*** src/include/pg_config.h.in	22 May 2003 16:39:30 -0000	1.47
--- src/include/pg_config.h.in	26 May 2003 17:38:32 -0000
***************
*** 465,470 ****
--- 465,473 ----
  /* Define to 1 if you have the <termios.h> header file. */
  #undef HAVE_TERMIOS_H
  
+ /* Define to 1 if you have the <pthread.h> header file. */
+ #undef HAVE_THREADS
+ 
  /* Define to 1 if your `struct tm' has `tm_zone'. Deprecated, use
     `HAVE_STRUCT_TM_TM_ZONE' instead. */
  #undef HAVE_TM_ZONE
Mon, 26 May 2003 13:44:04 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] ECPG thread-safety
On Mon, 2003-05-26 at 13:44, Bruce Momjian wrote:
> Rod Taylor wrote:
> -- Start of PGP signed section.
> > On Mon, 2003-05-26 at 13:06, Bruce Momjian wrote:
> > > Shridhar Daithankar wrote:
> > > > On Friday 28 March 2003 21:45, you wrote:
> > > > > For testing the library, I think it is enough to init an thread attr. like
> > > > > pthread_init_attr, that should be enough to test header and library.
> > > > 
> > > > And compiler flags, I forgot.. -pthread on freeBSD/gcc and -D_REENTRANT on 
> > > > linux at least. FreeBSD needs _THREAD_SAFE as well IIRC.
> > > 
> > > Are you saying FreeBSD actually has a -pthread compiler flag?  And Linux
> > > needs REENTRANT.  We can do that.  Here is an updated patch.  Of course,
> > > I need to run autoconf too.
> > 
> > If I'm not mistaken, you use -lpthread on FreeBSD 4.x, and -lc_r on
> > FreeBSD 5.x.
> 
> Thanks.  Patch updated and attached.  Are there any FreeBSD 3.X machines
> still around that have pthread.h?

You're more likely to run into a 2.x BSD box than a 3.x one :) Early
releases of 4.x were unusually good and very pain free for an upgrade
from 3.x.

I couldn't tell you about 3.x as I never did anything outside of
installing ports.
-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
26 May 2003 13:55:13 -0400
Rod Taylor <rbt@rbt.ca>
Re: [HACKERS] ECPG thread-safety
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> diff -c -c -r1.47 pg_config.h.in
> *** src/include/pg_config.h.in	22 May 2003 16:39:30 -0000	1.47
> --- src/include/pg_config.h.in	26 May 2003 16:57:57 -0000

Bruce, you do realize that you're not supposed to hand-edit
pg_config.h.in anymore?  Use autoheader to build it from configure.in.

			regards, tom lane

Mon, 26 May 2003 14:12:53 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] ECPG thread-safety 
Rod Taylor wrote:
-- Start of PGP signed section.
> On Mon, 2003-05-26 at 13:44, Bruce Momjian wrote:
> > Rod Taylor wrote:
> > -- Start of PGP signed section.
> > > On Mon, 2003-05-26 at 13:06, Bruce Momjian wrote:
> > > > Shridhar Daithankar wrote:
> > > > > On Friday 28 March 2003 21:45, you wrote:
> > > > > > For testing the library, I think it is enough to init an thread attr. like
> > > > > > pthread_init_attr, that should be enough to test header and library.
> > > > > 
> > > > > And compiler flags, I forgot.. -pthread on freeBSD/gcc and -D_REENTRANT on 
> > > > > linux at least. FreeBSD needs _THREAD_SAFE as well IIRC.
> > > > 
> > > > Are you saying FreeBSD actually has a -pthread compiler flag?  And Linux
> > > > needs REENTRANT.  We can do that.  Here is an updated patch.  Of course,
> > > > I need to run autoconf too.
> > > 
> > > If I'm not mistaken, you use -lpthread on FreeBSD 4.x, and -lc_r on
> > > FreeBSD 5.x.
> > 
> > Thanks.  Patch updated and attached.  Are there any FreeBSD 3.X machines
> > still around that have pthread.h?
> 
> You're more likely to run into a 2.x BSD box than a 3.x one :) Early
> releases of 4.x were unusually good and very pain free for an upgrade
> from 3.x.
> 
> I couldn't tell you about 3.x as I never did anything outside of
> installing ports.

When did pthread.h appear in FreeBSD?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 26 May 2003 14:16:26 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] ECPG thread-safety
On Mon, 2003-05-26 at 14:16, Bruce Momjian wrote:
> Rod Taylor wrote:
> -- Start of PGP signed section.
> > On Mon, 2003-05-26 at 13:44, Bruce Momjian wrote:
> > > Rod Taylor wrote:
> > > -- Start of PGP signed section.
> > > > On Mon, 2003-05-26 at 13:06, Bruce Momjian wrote:
> > > > > Shridhar Daithankar wrote:
> > > > > > On Friday 28 March 2003 21:45, you wrote:
> > > > > > > For testing the library, I think it is enough to init an thread attr. like
> > > > > > > pthread_init_attr, that should be enough to test header and library.
> > > > > > 
> > > > > > And compiler flags, I forgot.. -pthread on freeBSD/gcc and -D_REENTRANT on 
> > > > > > linux at least. FreeBSD needs _THREAD_SAFE as well IIRC.
> > > > > 
> > > > > Are you saying FreeBSD actually has a -pthread compiler flag?  And Linux
> > > > > needs REENTRANT.  We can do that.  Here is an updated patch.  Of course,
> > > > > I need to run autoconf too.
> > > > 
> > > > If I'm not mistaken, you use -lpthread on FreeBSD 4.x, and -lc_r on
> > > > FreeBSD 5.x.
> > > 
> > > Thanks.  Patch updated and attached.  Are there any FreeBSD 3.X machines
> > > still around that have pthread.h?
> > 
> > You're more likely to run into a 2.x BSD box than a 3.x one :) Early
> > releases of 4.x were unusually good and very pain free for an upgrade
> > from 3.x.
> > 
> > I couldn't tell you about 3.x as I never did anything outside of
> > installing ports.
> 
> When did pthread.h appear in FreeBSD?

2.2.0

-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
26 May 2003 14:18:06 -0400
Rod Taylor <rbt@rbt.ca>
Re: [HACKERS] ECPG thread-safety
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > diff -c -c -r1.47 pg_config.h.in
> > *** src/include/pg_config.h.in	22 May 2003 16:39:30 -0000	1.47
> > --- src/include/pg_config.h.in	26 May 2003 16:57:57 -0000
> 
> Bruce, you do realize that you're not supposed to hand-edit
> pg_config.h.in anymore?  Use autoheader to build it from configure.in.

You mentioned that recently, and I wasn't sure exactly how you did it,
and figured I would research it later.

I got it working and here is the updated patch --- thanks.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.253
diff -c -c -r1.253 configure.in
*** configure.in	22 May 2003 16:39:28 -0000	1.253
--- configure.in	26 May 2003 18:19:14 -0000
***************
*** 506,511 ****
--- 506,514 ----
                [  --without-zlib          do not use Zlib])
  
  
+ #
+ # Elf
+ #
  
  # Assume system is ELF if it predefines __ELF__ as 1,
  # otherwise believe host_os based default.
***************
*** 527,533 ****
--- 530,560 ----
  fi])
  AC_SUBST(ELF_SYS)
  
+ #
+ # Pthreads
+ #
  
+ AC_CHECK_HEADER(pthread.h,
+ 	[AC_DEFINE(HAVE_THREADS, 1, [Define to 1 if you have the threads interface.])])
+ if test ! -z "$HAVE_THREADS"
+ then	
+ 	case $host_os in
+ 		# BSD/OS and NetBSD require no special libraries or flags
+ 		netbsd*|bsdi*) ;;
+ 		freebsd4*) THREAD_CFLAGS="-pthread" ;;
+ 		freebsd*) THREAD_LIBS="-lc_r" ;;
+ 		linux*) THREAD_LIBS="-lpthread"
+ 			THREAD_CFLAGS="-D_REENTRANT" ;;
+ 	# other operating systems might fail because they have pthread.h but need
+ 	# special libs we don't know about yet.
+ 	esac
+ fi
+ AC_SUBST(THREAD_LIBS)
+ AC_SUBST(THREAD_CFLAGS)
+ 
+ #
+ # Assignments
+ #
  
  CPPFLAGS="$CPPFLAGS $INCLUDES"
  LDFLAGS="$LDFLAGS $LIBDIRS"
Index: src/Makefile.global.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/Makefile.global.in,v
retrieving revision 1.162
diff -c -c -r1.162 Makefile.global.in
*** src/Makefile.global.in	11 May 2003 20:50:53 -0000	1.162
--- src/Makefile.global.in	26 May 2003 18:19:15 -0000
***************
*** 152,157 ****
--- 152,160 ----
  TK_LIB_SPEC		= @TK_LIB_SPEC@
  TK_XINCLUDES		= @TK_XINCLUDES@
  
+ THREAD_CFLAGS		= @THREAD_CFLAGS@
+ THREAD_LIBS		= @THREAD_LIBS@
+ 
  have_docbook	= @have_docbook@
  DOCBOOKSTYLE	= @DOCBOOKSTYLE@
  COLLATEINDEX	= @COLLATEINDEX@
Index: src/include/pg_config.h.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/pg_config.h.in,v
retrieving revision 1.47
diff -c -c -r1.47 pg_config.h.in
*** src/include/pg_config.h.in	22 May 2003 16:39:30 -0000	1.47
--- src/include/pg_config.h.in	26 May 2003 18:19:16 -0000
***************
*** 465,470 ****
--- 465,473 ----
  /* Define to 1 if you have the <termios.h> header file. */
  #undef HAVE_TERMIOS_H
  
+ /* Define to 1 if you have the threads interface. */
+ #undef HAVE_THREADS
+ 
  /* Define to 1 if your `struct tm' has `tm_zone'. Deprecated, use
     `HAVE_STRUCT_TM_TM_ZONE' instead. */
  #undef HAVE_TM_ZONE
Mon, 26 May 2003 14:20:06 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] ECPG thread-safety
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Bruce, you do realize that you're not supposed to hand-edit
>> pg_config.h.in anymore?  Use autoheader to build it from configure.in.

> You mentioned that recently, and I wasn't sure exactly how you did it,
> and figured I would research it later.

You just run autoheader immediately after autoconf --- it's no different
from building configure from configure.in.

			regards, tom lane

Mon, 26 May 2003 14:25:57 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] ECPG thread-safety 
Rod Taylor wrote:
> > > You're more likely to run into a 2.x BSD box than a 3.x one :) Early
> > > releases of 4.x were unusually good and very pain free for an upgrade
> > > from 3.x.
> > > 
> > > I couldn't tell you about 3.x as I never did anything outside of
> > > installing ports.
> > 
> > When did pthread.h appear in FreeBSD?
> 
> 2.2.0

OK, updated patch for FreeBSD 2-4.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.253
diff -c -c -r1.253 configure.in
*** configure.in	22 May 2003 16:39:28 -0000	1.253
--- configure.in	26 May 2003 18:27:14 -0000
***************
*** 506,511 ****
--- 506,514 ----
                [  --without-zlib          do not use Zlib])
  
  
+ #
+ # Elf
+ #
  
  # Assume system is ELF if it predefines __ELF__ as 1,
  # otherwise believe host_os based default.
***************
*** 527,533 ****
--- 530,560 ----
  fi])
  AC_SUBST(ELF_SYS)
  
+ #
+ # Pthreads
+ #
  
+ AC_CHECK_HEADER(pthread.h,
+ 	[AC_DEFINE(HAVE_THREADS, 1, [Define to 1 if you have the threads interface.])])
+ if test ! -z "$HAVE_THREADS"
+ then	
+ 	case $host_os in
+ 		# BSD/OS and NetBSD require no special libraries or flags
+ 		netbsd*|bsdi*) ;;
+ 		freebsd2*|freebsd3*|freebsd4*) THREAD_CFLAGS="-pthread" ;;
+ 		freebsd*) THREAD_LIBS="-lc_r" ;;
+ 		linux*) THREAD_LIBS="-lpthread"
+ 			THREAD_CFLAGS="-D_REENTRANT" ;;
+ 	# other operating systems might fail because they have pthread.h but need
+ 	# special libs we don't know about yet.
+ 	esac
+ fi
+ AC_SUBST(THREAD_LIBS)
+ AC_SUBST(THREAD_CFLAGS)
+ 
+ #
+ # Assignments
+ #
  
  CPPFLAGS="$CPPFLAGS $INCLUDES"
  LDFLAGS="$LDFLAGS $LIBDIRS"
Index: src/Makefile.global.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/Makefile.global.in,v
retrieving revision 1.162
diff -c -c -r1.162 Makefile.global.in
*** src/Makefile.global.in	11 May 2003 20:50:53 -0000	1.162
--- src/Makefile.global.in	26 May 2003 18:27:16 -0000
***************
*** 152,157 ****
--- 152,160 ----
  TK_LIB_SPEC		= @TK_LIB_SPEC@
  TK_XINCLUDES		= @TK_XINCLUDES@
  
+ THREAD_CFLAGS		= @THREAD_CFLAGS@
+ THREAD_LIBS		= @THREAD_LIBS@
+ 
  have_docbook	= @have_docbook@
  DOCBOOKSTYLE	= @DOCBOOKSTYLE@
  COLLATEINDEX	= @COLLATEINDEX@
Index: src/include/pg_config.h.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/pg_config.h.in,v
retrieving revision 1.47
diff -c -c -r1.47 pg_config.h.in
*** src/include/pg_config.h.in	22 May 2003 16:39:30 -0000	1.47
--- src/include/pg_config.h.in	26 May 2003 18:27:19 -0000
***************
*** 465,470 ****
--- 465,473 ----
  /* Define to 1 if you have the <termios.h> header file. */
  #undef HAVE_TERMIOS_H
  
+ /* Define to 1 if you have the threads interface. */
+ #undef HAVE_THREADS
+ 
  /* Define to 1 if your `struct tm' has `tm_zone'. Deprecated, use
     `HAVE_STRUCT_TM_TM_ZONE' instead. */
  #undef HAVE_TM_ZONE
Mon, 26 May 2003 14:28:41 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] ECPG thread-safety
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> Bruce, you do realize that you're not supposed to hand-edit
> >> pg_config.h.in anymore?  Use autoheader to build it from configure.in.
> 
> > You mentioned that recently, and I wasn't sure exactly how you did it,
> > and figured I would research it later.
> 
> You just run autoheader immediately after autoconf --- it's no different
> from building configure from configure.in.
> 

Yes, I see now.  I thought autoheader was for generating include
dependencies, actually.
-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 26 May 2003 14:32:33 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] ECPG thread-safety
Shridhar Daithankar wrote:

>2) Native freeBSD threads
>pthread.h in /usr/include and lc_r
>
>  
>
Do you know if FreeBSD supports pthread_rwlock with 
PTHREAD_PROCESS_SHARED? I'm trying to replace the LWLocks with 
pthread_rwlocks.

What about other Unices?
--
    Manfred


Sun, 01 Jun 2003 11:10:46 +0200
Manfred Spraul <manfred@colorfullife.com>
Re: ECPG thread-safety
On 1 Jun 2003 at 11:10, Manfred Spraul wrote:

> Shridhar Daithankar wrote:
> 
> >2) Native freeBSD threads
> >pthread.h in /usr/include and lc_r
> >
> >  
> >
> Do you know if FreeBSD supports pthread_rwlock with 
> PTHREAD_PROCESS_SHARED? I'm trying to replace the LWLocks with 
> pthread_rwlocks.
> 
> What about other Unices?

I am sorry for late reply. Hasn't been able to boot into freeBSD due to day job 
for weeks. I will check and let you know.

Bye
 Shridhar

--
We'll pivot at warp 2 and bring all tubes to bear, Mr. Sulu!


Mon, 02 Jun 2003 12:25:03 +0530
"Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>
Re: ECPG thread-safety
On Sun, 15 Jun 2003 09:06 pm, you wrote:
> [Sorry for the late answer. Somehow I didn't notice your mail wainting
> for an answer.]

No problems, I'd kinda forgotten myself.

> On Tue, Apr 22, 2003 at 01:45:40PM +1000, Philip Yarra wrote:
> > Bison 1.35 and 1.50 both have bugs that prevent successful compilation,
> > so I moved to 1.85. This appears to work okay. Is there some way during
> > configure to check for broken bison versions and complain loudly?
>
> Not that I know of.

I wondered if we could do something like:
BISON_VERSION=`bison -V | head -n 1 | awk '{print $4 }'`
during configure, compare the result to known buggy versions, and take some 
sort of action based on that? I haven't delved into configure though, so not 
sure how to implement "some sort of action".

I think it is fairly important to try to detect these buggy bisons if the same 
problem will be exposed in release versions of the source - it cost me quite 
a few hours trying to figure out why make was failing. I'd like to save other 
people the hassle (and that list would include people running RedHat Linux 
7.3, which includes the bison 1.35).

Regards, Philip.



Mon, 16 Jun 2003 11:10:58 +1000
Philip Yarra <philip@utiba.com>
Re: ECPG CVS version problems
Philip Yarra <philip@utiba.com> writes:
> Bison 1.35 and 1.50 both have bugs that prevent successful compilation,
> so I moved to 1.85. This appears to work okay. Is there some way during
> configure to check for broken bison versions and complain loudly?

Uh, this is done as of a few days ago.  Or is the check not working?

			regards, tom lane

Sun, 15 Jun 2003 22:49:34 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: ECPG CVS version problems 
On Mon, 16 Jun 2003 12:49 pm, Tom Lane wrote:
> Philip Yarra <philip@utiba.com> writes:
> > Bison [blah blah]

> Uh, this is done as of a few days ago.  Or is the check not working?
>
> 			regards, tom lane

Tom, this post relates to problems I had with the CVS build around April 22... 
Michael's reply was somewhat delayed. So you can probably ignore it.

I just did a test build on a machine with bison 1.35, and there were no 
complaints regarding its version - I assume that a way was found to make 
older versions of bison work (which is definitely preferable)? Whatever was 
done, it seems to have done the trick.

Regards, Philip.

Mon, 16 Jun 2003 14:04:55 +1000
Philip Yarra <philip@utiba.com>
Re: ECPG CVS version problems
Philip Yarra <philip@utiba.com> writes:
> I just did a test build on a machine with bison 1.35, and there were no 
> complaints regarding its version

You sure?  I see in configure's output

...
checking whether it is possible to strip libraries... yes
checking for bison... bison -y
configure: WARNING:
*** The installed version of Bison is too old.  PostgreSQL needs
*** Bison version 1.875 or later.
checking for perl... /usr/bin/perl
checking for main in -lbsd... yes
...

which admittedly is easy to miss, but it's there.  (The reason it's not
a hard error is that you don't actually need bison unless you don't have
up-to-date copies of the derived files made by bison.  This should not
be the case when using a snapshot, only when building from a CVS pull.)

> I assume that a way was found to make 
> older versions of bison work

You assume wrong.  Not all the .y files need recent bison, but the ones
that do will fail badly.  The issues are grammar-size limits for bison
less than about 1.50, and outright bison bugs for versions from there to
1.875.  We do not have workarounds.

			regards, tom lane

Mon, 16 Jun 2003 00:35:04 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: ECPG CVS version problems 

I wonder is we should check for *dev on the version string and make
missing bison version a hard error in these cases.

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

Tom Lane wrote:
> Philip Yarra <philip@utiba.com> writes:
> > I just did a test build on a machine with bison 1.35, and there were no 
> > complaints regarding its version
> 
> You sure?  I see in configure's output
> 
> ...
> checking whether it is possible to strip libraries... yes
> checking for bison... bison -y
> configure: WARNING:
> *** The installed version of Bison is too old.  PostgreSQL needs
> *** Bison version 1.875 or later.
> checking for perl... /usr/bin/perl
> checking for main in -lbsd... yes
> ...
> 
> which admittedly is easy to miss, but it's there.  (The reason it's not
> a hard error is that you don't actually need bison unless you don't have
> up-to-date copies of the derived files made by bison.  This should not
> be the case when using a snapshot, only when building from a CVS pull.)
> 
> > I assume that a way was found to make 
> > older versions of bison work
> 
> You assume wrong.  Not all the .y files need recent bison, but the ones
> that do will fail badly.  The issues are grammar-size limits for bison
> less than about 1.50, and outright bison bugs for versions from there to
> 1.875.  We do not have workarounds.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
>                http://archives.postgresql.org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 16 Jun 2003 01:07:59 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: ECPG CVS version problems
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I wonder is we should check for *dev on the version string and make
> missing bison version a hard error in these cases.

No, because that breaks snapshot tarballs.

You could possibly make some argument for going out and actually
checking the existence and timestamp of each bison-derived file that
should be there, and erroring out only if it looks like bison is really
gonna get invoked during the build.  But that seems like an
unmaintainable kluge to me.

It's not like the bison-related build failures aren't pretty obvious.
I think the configure-time test is doing its job by producing a
warning.  If people don't notice it, well, they'll find out later.
We do assume some level of technical competence for those who build
from CVS pulls ...

			regards, tom lane

Mon, 16 Jun 2003 01:18:24 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: ECPG CVS version problems 
On Mon, 16 Jun 2003 02:35 pm, Tom Lane wrote:
> Philip Yarra <philip@utiba.com> writes:
> > I just did a test build on a machine with bison 1.35, and there were no
> > complaints regarding its version
>
> You sure?  I see [it] in configure's output

Oh, yes, well so it is. Sorry about that.

>  (The reason it's not
> a hard error is that you don't actually need bison unless you don't have
> up-to-date copies of the derived files made by bison.  This should not
> be the case when using a snapshot, only when building from a CVS pull.)

Provided preproc.y has changed... `make clean` does not remove the output of 
bison, I found. When I copied the CVS source from my workstation to the 
machine with older bison I didn't realise that, hence the confusion.

> > I assume that a way was found to make
> > older versions of bison work
>
> You assume wrong.  

Yep. Part of the learning-curve, I suppose. I'll get there.

Regards, Philip.

Mon, 16 Jun 2003 15:58:13 +1000
Philip Yarra <philip@utiba.com>
Re: ECPG CVS version problems
On Mon, Jun 16, 2003 at 02:04:55PM +1000, Philip Yarra wrote:
> I just did a test build on a machine with bison 1.35, and there were no 
> complaints regarding its version - I assume that a way was found to make 
> older versions of bison work (which is definitely preferable)? Whatever was 
> done, it seems to have done the trick.

I think we still have preproc.c auto-generated from preproc.y in our
archive, don't we? If so, most users wanting to compile ecpg do not need
bison at all as they can use this one. Or do I miss something?

Michael
-- 
Michael Meskes
Email: Michael@Fam-Meskes.De
ICQ: 179140304, AIM: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Mon, 16 Jun 2003 08:01:11 +0200
Michael Meskes <meskes@postgresql.org>
Re: ECPG CVS version problems
Michael Meskes <meskes@postgresql.org> writes:
> I think we still have preproc.c auto-generated from preproc.y in our
> archive, don't we?

It's not in CVS (and shouldn't be IMHO); but it is built during tarball
creation (including nightly snapshots).  So only people who use CVS
directly need to have bison.

			regards, tom lane

Mon, 16 Jun 2003 09:22:11 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: ECPG CVS version problems 