Обсуждение: Linking legacy PHP stuff
I'm posting this in the hope that someone else has encountered this
problem already and has solved it - if not I'll just have to plough into
the source and sort it myself.
I still have some Web apps written in PHP/FI 2.0.1. Yes, I know it's
hopelessly out of date, but they work, and they're not important enough
to be worth rewriting. Unfortunately PHP/FI 2.0 won't compile against
Postgres 7. It complains:
pg95.c:495: dereferencing pointer to incomplete type
make: *** [pg95.o] Error
1
What's actually going on at the time is:
/* check result */
result = pg_get_result(res_ind);
if (result == NULL) {
Error("Unable to find result index %s", res_ind);
Push("", STRING);
return;
}
curr_conn = result->conn;
if ((curr_conn == NULL) && (pgTypeRes==0)) {
Error("Unable to get connection for tuple typing in
pg_result")\;
Push("", STRING);
return;
}
where result is defined
PGresult *result=NULL;
Anyone already got a fix? If not, anyone got any suggestions as to what
I start hacking? What has changed in the PGresult structure between 6.3
(when it worked for certain) and 7.0.2 (when it for certain doesn't).
Cheers
Simon
--
Simon Brooke, Technical Director, Weft Technology Ltd --
http://www.weft.co.uk/
the weft is not just what binds the web: it is what makes it a web
Simon Brooke wrote: > Anyone already got a fix? If not, anyone got any suggestions as to what > I start hacking? What has changed in the PGresult structure between 6.3 > (when it worked for certain) and 7.0.2 (when it for certain doesn't). At 6.4, there was a protocol change that renders clients for libpq version 1 incapable of connecting or using servers using protocol version 2. Thus, unless you want to do surgery on PHP/FI 2, you will have to stick with PostgreSQL 6.3.2 or earlier. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
> At 6.4, there was a protocol change that renders clients for libpq
> version 1 incapable of connecting or using servers using protocol
> version 2. Thus, unless you want to do surgery on PHP/FI 2, you will
> have to stick with PostgreSQL 6.3.2 or earlier.
This is false (not to mention irrelevant to Simon's problem), because
current servers still accept protocol version 1. What you cannot do
at the moment is use a new libpq with an old server.
regards, tom lane
Simon Brooke <simon@weft.co.uk> writes:
> curr_conn = result->conn;
> if ((curr_conn == NULL) && (pgTypeRes==0)) {
Get rid of curr_conn and the ensuing test on same, is my advice.
This code should never have been reaching inside PGresult to begin
with...
regards, tom lane
Tom Lane wrote:
>
> Simon Brooke <simon@weft.co.uk> writes:
> > curr_conn = result->conn;
> > if ((curr_conn == NULL) && (pgTypeRes==0)) {
>
> Get rid of curr_conn and the ensuing test on same, is my advice.
> This code should never have been reaching inside PGresult to begin
> with...
Thanks, this worked.
--
Simon Brooke, Technical Director, Weft Technology Ltd --
http://www.weft.co.uk/
the weft is not just what binds the web: it is what makes it a web
On Fri, 18 Aug 2000, Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > At 6.4, there was a protocol change that renders clients for libpq > > version 1 incapable of connecting or using servers using protocol > > version 2. Thus, unless you want to do surgery on PHP/FI 2, you will > > have to stick with PostgreSQL 6.3.2 or earlier. > This is false (not to mention irrelevant to Simon's problem), because > current servers still accept protocol version 1. What you cannot do > at the moment is use a new libpq with an old server. My error. However, I _have_ seen memory leaks and other problems with a client that was statically linked with a pre-6.4 libpq on post 6.4 that worked perfectly with pre-6.4 server. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Sat, 19 Aug 2000, Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > However, I _have_ seen memory leaks and other problems with a client > > that was statically linked with a pre-6.4 libpq on post 6.4 that worked > > perfectly with pre-6.4 server. > Interesting --- this would imply some problem in the current backend's > handling of the v1 protocol, I think. Is it worth your time to dig > into it further and see where the leak is coming from? I'm not sure > I care very much about pre-6.4 code myself, but am willing to look > at the problem if you can provide specifics. I'll see what can find -- and I mean that literally, as that client may or may not still be available in that form on my disk (AOLserver 2.2.1 through AOLserver 2.3b4 binary distribution's postgres.so -- the 2.3.2, 2.3.3, and 3.0 drivers don't exhibit the problem....) -- and the AOLserver site no longer distributes the closed source versions -- only the open source AOLserver 3, which is also available in binary form, but linked to a post-6.4 libpq. The symptom was, on any database error whatsoever, the database connection would blowup and cause a segmentation fault for the master thread in the multithreaded AOLserver core -- which is _not_ supposed to happen. This would lock up the entire server process, requireing kill -9 to recover. Recompiling the postgres driver and linking against a post-6.4 libpq cleared the problem. The problem did not happen if a pre-6.4 server was in use. I ran for two years with the old postgres.so's and 6.2.1/6.3.2 with little to no incident -- then I upgraded to 6.5, and had to recompile the driver to get things right. I could have been the libpq.a that the postgres driver was linked against -- I asked the developers at that time what version it was, and they replied that it was so old that they had no idea. That's when I realized I should have been recompiling and relinking all along! :-) I _do_ know the docs to the driver mentioned Postgres95 1.0.1...... But, that's about the same age as PHP/FI 2, isnt' it? Of course, you found Simon's problem -- for which I am glad. Much simpler than I erroneously thought. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
> However, I _have_ seen memory leaks and other problems with a client
> that was statically linked with a pre-6.4 libpq on post 6.4 that worked
> perfectly with pre-6.4 server.
Interesting --- this would imply some problem in the current backend's
handling of the v1 protocol, I think. Is it worth your time to dig
into it further and see where the leak is coming from? I'm not sure
I care very much about pre-6.4 code myself, but am willing to look
at the problem if you can provide specifics.
regards, tom lane