pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedPHP and PostgreSQL
27+ messages / 12 participants
[nested] [flat]
* PHP and PostgreSQL
@ 2000-12-27 05:56 Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 4 replies; 27+ messages in thread
From: Bruce Momjian @ 2000-12-27 05:56 UTC (permalink / raw)
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>; pgsql-interfaces
I have been asked by the major PHP developer Rasmus Lerdorf to see if
the PostgreSQL/PHP interface needs any improvements.
Is the current PostgreSQL interface module in PHP adequate? Does it
support all the current libpq features?
If not, would someone submit some patches to the PHP folks. They want
us to work well with PHP. They are basically encouraging us to improve
it in any way we can.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: PHP and PostgreSQL
@ 2000-12-27 13:46 mlw <markw@mohawksoft.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
3 siblings, 0 replies; 27+ messages in thread
From: mlw @ 2000-12-27 13:46 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
Bruce Momjian wrote:
>
> I have been asked by the major PHP developer Rasmus Lerdorf to see if
> the PostgreSQL/PHP interface needs any improvements.
>
> Is the current PostgreSQL interface module in PHP adequate? Does it
> support all the current libpq features?
>
> If not, would someone submit some patches to the PHP folks. They want
> us to work well with PHP. They are basically encouraging us to improve
> it in any way we can.
In a current project, I am using Postgres, Oracle, and PHP. I think
PHP's API is very complete and usable, I can't think of anything we've
run into that was a result of PHP lacking a feature.
The only thing I'd like to see would be an Oracle construct moved to
Postgres. The idea that we can "prepare" a statement then execute it
multiple times without going through the planner more than once. This
would also require the ability to create and set arbitrary variables in
a Postgres session.
Since these are programmatic queries, only a handful of different SQL
queries are ever executed. The ability to cache the planned query tree
(is this the right terminology?) in a shared block, and simply reuse it,
in the multiple back-ends, with a new variable value, would speed up
some of the more complex queries, I guess.
--
http://www.mohawksoft.com
^ permalink raw reply [nested|flat] 27+ messages in thread
* RE: [HACKERS] PHP and PostgreSQL
@ 2000-12-27 13:54 Matthew <matt@ctlno.com>
0 siblings, 4 replies; 27+ messages in thread
From: Matthew @ 2000-12-27 13:54 UTC (permalink / raw)
To: 'Bruce Momjian' <pgman@candle.pha.pa.us>; PostgreSQL-development <pgsql-hackers@postgreSQL.org>; pgsql-interfaces
I have been asked by the major PHP developer Rasmus Lerdorf to see
if
the PostgreSQL/PHP interface needs any improvements.
Is the current PostgreSQL interface module in PHP adequate? Does it
support all the current libpq features?
The only problem we have run into (and I have heard of others having this
problem also) is with persistent connections. I have seen discussion on
persistent connection problems but I'm not sure the problem was ever
resolved. The problem we have seen is that when using persistent
connections the web server doesn't seen to reuse the connections or somthing
to that effect. The result being that we eventually use up our postgres
limit of 48 connections and nothing can connect to postgre anymore. It is
possible that this is a configuration problem that we haven't sufficiently
investigated, but I meniton it because I have heard other talk of this.
Anyone have more information?
Matthew
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: RE: [HACKERS] PHP and PostgreSQL
@ 2000-12-27 14:14 Adam Lang <aalang@rutgersinsurance.com>
parent: Matthew <matt@ctlno.com>
3 siblings, 0 replies; 27+ messages in thread
From: Adam Lang @ 2000-12-27 14:14 UTC (permalink / raw)
To: pgsql-interfaces
Yeah, this is not a "bug", but a feature. :)
In a nutshell, the persistent connection number is not how many persistent
connections there are available to the webserver. It is the number
available per webserver PROCESS.
So, if you have 5 persistent connections, but 10 webserver processes open,
you have 50 persistent connections open.
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
http://www.rutgersinsurance.com
----- Original Message -----
From: "Matthew" <matt@ctlno.com>
To: "'Bruce Momjian'" <pgman@candle.pha.pa.us>; "PostgreSQL-development"
<pgsql-hackers@postgresql.org>; "PostgreSQL-interfaces"
<pgsql-interfaces@postgresql.org>
Sent: Wednesday, December 27, 2000 8:54 AM
Subject: [INTERFACES] RE: [HACKERS] PHP and PostgreSQL
>
> I have been asked by the major PHP developer Rasmus Lerdorf to see
> if
> the PostgreSQL/PHP interface needs any improvements.
>
> Is the current PostgreSQL interface module in PHP adequate? Does it
> support all the current libpq features?
>
>
> The only problem we have run into (and I have heard of others having this
> problem also) is with persistent connections. I have seen discussion on
> persistent connection problems but I'm not sure the problem was ever
> resolved. The problem we have seen is that when using persistent
> connections the web server doesn't seen to reuse the connections or
somthing
> to that effect. The result being that we eventually use up our postgres
> limit of 48 connections and nothing can connect to postgre anymore. It is
> possible that this is a configuration problem that we haven't sufficiently
> investigated, but I meniton it because I have heard other talk of this.
> Anyone have more information?
>
> Matthew
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: PHP and PostgreSQL
@ 2000-12-27 14:39 Daniele Orlandi <daniele@orlandi.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
3 siblings, 0 replies; 27+ messages in thread
From: Daniele Orlandi @ 2000-12-27 14:39 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>; pgsql-interfaces
Bruce Momjian wrote:
>
> I have been asked by the major PHP developer Rasmus Lerdorf to see if
> the PostgreSQL/PHP interface needs any improvements.
>
> Is the current PostgreSQL interface module in PHP adequate? Does it
> support all the current libpq features?
>
> If not, would someone submit some patches to the PHP folks. They want
> us to work well with PHP. They are basically encouraging us to improve
> it in any way we can.
If I can put my 0.02 Euros, I think there are two issues that deserve to
be fixed, both are relative to persistent connections.
The first is that the transaction state is (obviously) kept between
connections. This is not a problem in itself, but there are some
situations where the transaction block is not closed with COMMIT or
ABORT with the obvious consequencies when the connection is reused (and
with the locks not released). As a workaround I registered a shutdown
funcion that sends an ABORT command every time a script finishes his
processing but this results in a "Not in trasaction block" error most of
the time (harmless but pretty annoying).
IMHO there should be some sort of lightweight reset that puts the
connection in its pristine state without the need to fork a backend
againg and reopen the TCP connection.
The second is that if PostgreSQL is restarted, PHP doesn't detect that
and an error message is seen for every persistent connection. IMHO PHP
should detect a closed connection and clear the connections pool.
Bye!
--
Daniele
-------------------------------------------------------------------------------
Daniele Orlandi - Utility Line Italia - http://www.orlandi.com
Via Mezzera 29/A - 20030 - Seveso (MI) - Italy
-------------------------------------------------------------------------------
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: PHP and PostgreSQL
@ 2000-12-27 15:09 Rod Taylor <rbt@zort.on.ca>
parent: Matthew <matt@ctlno.com>
3 siblings, 1 reply; 27+ messages in thread
From: Rod Taylor @ 2000-12-27 15:09 UTC (permalink / raw)
To: pgsql-hackers@postgresql.org
> The only problem we have run into (and I have heard of others having this
> problem also) is with persistent connections. I have seen discussion on
> persistent connection problems but I'm not sure the problem was ever
> resolved. The problem we have seen is that when using persistent
> connections the web server doesn't seen to reuse the connections or
somthing
> to that effect. The result being that we eventually use up our postgres
> limit of 48 connections and nothing can connect to postgre anymore. It is
> possible that this is a configuration problem that we haven't sufficiently
> investigated, but I meniton it because I have heard other talk of this.
> Anyone have more information?
The *real* problem with persistent connections is:
Script1: BEGIN;
Script1: UPDATE table set row = 'things';
Script2: Insert into table (id) values ('bad data');
Script1: COMMIT;
Since script2 managed to do a BAD insert in the middle of script1's
transaction, the transaction in script1 fails. Obvious solution? Don't do
connection sharing when a transaction is enabled. The whole persistent
connection thing is only valid for mysql as it's the only thing that doesn't
really support transactions (and even thats partially changed).
They need to look for stuff going through (keywords like BEGIN) and 'lock'
that connection to the single entity that opened it.
It's much easier to write your own. I wrote a few functions like:
get_connection('DB PARMS');
begin_transaction();
commit_transaction();
close_connection();
All of this is done in a class which has knowledge of all connections that a
script is currently using. Beginning a transaction locks down the
connection from use by any other handler, they're all bumped to another one.
Problem? It requires atleast 1 connection per page, but since they're
actually dropped at close it's not so bad.
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: PHP and PostgreSQL
@ 2000-12-27 15:15 mlw <markw@mohawksoft.com>
parent: Matthew <matt@ctlno.com>
3 siblings, 0 replies; 27+ messages in thread
From: mlw @ 2000-12-27 15:15 UTC (permalink / raw)
To: Matthew <matt@ctlno.com>; +Cc: 'Bruce Momjian' <pgman@candle.pha.pa.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
Matthew wrote:
>
> I have been asked by the major PHP developer Rasmus Lerdorf to see
> if
> the PostgreSQL/PHP interface needs any improvements.
>
> Is the current PostgreSQL interface module in PHP adequate? Does it
> support all the current libpq features?
>
> The only problem we have run into (and I have heard of others having this
> problem also) is with persistent connections. I have seen discussion on
> persistent connection problems but I'm not sure the problem was ever
> resolved. The problem we have seen is that when using persistent
> connections the web server doesn't seen to reuse the connections or somthing
> to that effect. The result being that we eventually use up our postgres
> limit of 48 connections and nothing can connect to postgre anymore. It is
> possible that this is a configuration problem that we haven't sufficiently
> investigated, but I meniton it because I have heard other talk of this.
> Anyone have more information?
>
I have not seen this, though now that you mention it, I will be on the
lookout.
We have a load balenced system with [n] apache servers, each with a
local Postgres database that receives updates from a master.
On the local web servers, we have done a good deal of load testing. Our
apache instances are pretty persistent, i.e. we do not have a time out
or maximum number of transactions. I never see more more postgres
instances than I have apache instances. We are using pg_pConnect to
connect to the postgres system.
The behavior may differ if the database is on a different system.
--
http://www.mohawksoft.com
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: PHP and PostgreSQL
@ 2000-12-27 16:24 Adam Lang <aalang@rutgersinsurance.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
3 siblings, 1 reply; 27+ messages in thread
From: Adam Lang @ 2000-12-27 16:24 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
I'd say the most important thing would be to get it upto speed with 7.1.
Make sure PHP supports large objects and the TOAST properly.
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
http://www.rutgersinsurance.com
----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
To: "PostgreSQL-development" <pgsql-hackers@postgresql.org>;
"PostgreSQL-interfaces" <pgsql-interfaces@postgresql.org>
Sent: Wednesday, December 27, 2000 12:56 AM
Subject: [INTERFACES] PHP and PostgreSQL
> I have been asked by the major PHP developer Rasmus Lerdorf to see if
> the PostgreSQL/PHP interface needs any improvements.
>
> Is the current PostgreSQL interface module in PHP adequate? Does it
> support all the current libpq features?
>
> If not, would someone submit some patches to the PHP folks. They want
> us to work well with PHP. They are basically encouraging us to improve
> it in any way we can.
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [HACKERS] PHP and PostgreSQL
@ 2000-12-27 16:45 Karl DeBisschop <karl@debisschop.net>
parent: Matthew <matt@ctlno.com>
3 siblings, 1 reply; 27+ messages in thread
From: Karl DeBisschop @ 2000-12-27 16:45 UTC (permalink / raw)
To: ; +Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>; pgsql-interfaces
Matthew wrote:
>
> I have been asked by the major PHP developer Rasmus Lerdorf to see
> if
> the PostgreSQL/PHP interface needs any improvements.
>
> Is the current PostgreSQL interface module in PHP adequate? Does it
> support all the current libpq features?
>
> The only problem we have run into (and I have heard of others having this
> problem also) is with persistent connections. I have seen discussion on
> persistent connection problems but I'm not sure the problem was ever
> resolved. The problem we have seen is that when using persistent
> connections the web server doesn't seen to reuse the connections or somthing
> to that effect. The result being that we eventually use up our postgres
> limit of 48 connections and nothing can connect to postgre anymore. It is
> possible that this is a configuration problem that we haven't sufficiently
> investigated, but I meniton it because I have heard other talk of this.
> Anyone have more information?
Persistent connections behave exactly as advertised. Each apache process
sets up and maintains persistent connections as needed. The problem is
that for a typical web server, there are so many subprocesses that
persistent connections are probably consume more resources than they
save, unless they are combined with connection pooling across ALL the
apache processes.
Implementation of connection pooling is by far the most serious
shortcoming of the current implementation, IMHO.
I would dearly love to see this addressed as our postgresql database
sees connections from about 300 servers for 6 databases. Since our
postgresql server cannot support 1800 simultaneous active backends,
persistent connections are useless without pooling. So instead we
initiate 10 or more backends every second for generally very simple
queries. Most of the queries are pretty simple, so I would not be at all
surprised if we sent more system resources opening connections than we
do actually answering queries
--
Karl DeBisschop kdebisschop@alert.infoplease.com
Learning Network/Information Please http://www.infoplease.com
Netsaint Plugin Developer kdebisschop@users.sourceforge.net
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: PHP and PostgreSQL
@ 2000-12-27 17:03 Frank Joerdens <frank@joerdens.de>
parent: Adam Lang <aalang@rutgersinsurance.com>
0 siblings, 1 reply; 27+ messages in thread
From: Frank Joerdens @ 2000-12-27 17:03 UTC (permalink / raw)
To: Adam Lang <aalang@rutgersinsurance.com>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
Adam Lang wrote:
>
> I'd say the most important thing would be to get it upto speed with 7.1.
> Make sure PHP supports large objects and the TOAST properly.
What would be the problem there? As I understand TOAST, the application shouldn't take any
notice of it's inner workings whatsoever . . . also, I've used TOAST with PHP (i.e. I've
managed to insert more than 8 k into a row with the rowsize set to 8 k), without any
trouble. I don't know about large objects but as I heard, the interface didn't change?!
- Frank
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: PHP and PostgreSQL
@ 2000-12-27 18:46 Adam Lang <aalang@rutgersinsurance.com>
parent: Frank Joerdens <frank@joerdens.de>
0 siblings, 2 replies; 27+ messages in thread
From: Adam Lang @ 2000-12-27 18:46 UTC (permalink / raw)
To: ; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
I thought I saw mention on the interfaces list that the ODBC driver needed
to be modified to properly use the large objects.
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
http://www.rutgersinsurance.com
----- Original Message -----
From: "Frank Joerdens" <frank@joerdens.de>
To: "Adam Lang" <aalang@rutgersinsurance.com>
Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>; "PostgreSQL-development"
<pgsql-hackers@postgresql.org>; "PostgreSQL-interfaces"
<pgsql-interfaces@postgresql.org>
Sent: Wednesday, December 27, 2000 12:03 PM
Subject: Re: [INTERFACES] PHP and PostgreSQL
> Adam Lang wrote:
> >
> > I'd say the most important thing would be to get it upto speed with 7.1.
> > Make sure PHP supports large objects and the TOAST properly.
>
> What would be the problem there? As I understand TOAST, the application
shouldn't take any
> notice of it's inner workings whatsoever . . . also, I've used TOAST with
PHP (i.e. I've
> managed to insert more than 8 k into a row with the rowsize set to 8 k),
without any
> trouble. I don't know about large objects but as I heard, the interface
didn't change?!
>
> - Frank
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: PHP and PostgreSQL
@ 2000-12-27 21:30 Adam Lang <aalang@rutgersinsurance.com>
parent: Frank Joerdens <frank@joerdens.de>
0 siblings, 0 replies; 27+ messages in thread
From: Adam Lang @ 2000-12-27 21:30 UTC (permalink / raw)
To: ; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
I agree, but I figured that if the 7.1 upgrade breaks some of the large
object interface in the ODBC code, it may possibly break some of the
interface in the php-psql code. That's why I said it should probably be
checked. ;)
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
http://www.rutgersinsurance.com
----- Original Message -----
From: "Frank Joerdens" <frank@joerdens.de>
To: "Adam Lang" <aalang@rutgersinsurance.com>
Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>;
"PostgreSQL-interfaces" <pgsql-interfaces@postgresql.org>
Sent: Wednesday, December 27, 2000 5:22 PM
Subject: Re: [INTERFACES] PHP and PostgreSQL
> Adam Lang wrote:
> >
> > I thought I saw mention on the interfaces list that the ODBC driver
needed
> > to be modified to properly use the large objects.
>
> You normally wouldn't use ODBC to access Postgres from PHP but rather
> the Postgres-specific interface. You _can_ use ODBC as well but normally
> that doesn't provide any advantage. If your concern is database
> abstraction, there are several libraries for PHP that provide it in
> varying degrees, ODBC would be just one, possibly not optimal, solution
> for the problem. Generally, from following the PHP lists and looking at
> columns on, for instance, phpbuilder.com, PHP folks don't seem to
> concerned with the abstraction issue, as far as I can make out anyway
> (just my impression). Rasmus' question, IMHO, was about the PHP/Postgres
> interface, not about ODBC.
>
> - Frank
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: PHP and PostgreSQL
@ 2000-12-27 22:22 Frank Joerdens <frank@joerdens.de>
parent: Adam Lang <aalang@rutgersinsurance.com>
1 sibling, 1 reply; 27+ messages in thread
From: Frank Joerdens @ 2000-12-27 22:22 UTC (permalink / raw)
To: Adam Lang <aalang@rutgersinsurance.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
Adam Lang wrote:
>
> I thought I saw mention on the interfaces list that the ODBC driver needed
> to be modified to properly use the large objects.
You normally wouldn't use ODBC to access Postgres from PHP but rather
the Postgres-specific interface. You _can_ use ODBC as well but normally
that doesn't provide any advantage. If your concern is database
abstraction, there are several libraries for PHP that provide it in
varying degrees, ODBC would be just one, possibly not optimal, solution
for the problem. Generally, from following the PHP lists and looking at
columns on, for instance, phpbuilder.com, PHP folks don't seem to
concerned with the abstraction issue, as far as I can make out anyway
(just my impression). Rasmus' question, IMHO, was about the PHP/Postgres
interface, not about ODBC.
- Frank
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: PHP and PostgreSQL
@ 2000-12-27 22:22 Frank Joerdens <frank@joerdens.de>
parent: Adam Lang <aalang@rutgersinsurance.com>
1 sibling, 0 replies; 27+ messages in thread
From: Frank Joerdens @ 2000-12-27 22:22 UTC (permalink / raw)
To: Adam Lang <aalang@rutgersinsurance.com>; +Cc: pgsql-interfaces
Adam Lang wrote:
>
> I thought I saw mention on the interfaces list that the ODBC driver needed
> to be modified to properly use the large objects.
You normally wouldn't use ODBC to access Postgres from PHP but rather
the Postgres-specific interface. You _can_ use ODBC as well but normally
that doesn't provide any advantage. If your concern is database
abstraction, there are several libraries for PHP that provide it in
varying degrees, ODBC would be just one, possibly not optimal, solution
for the problem. Generally, from following the PHP lists and looking at
columns on, for instance, phpbuilder.com, PHP folks don't seem to
concerned with the abstraction issue, as far as I can make out anyway
(just my impression).
- Frank
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [HACKERS] PHP and PostgreSQL
@ 2000-12-28 01:58 Adam Haberlach <adam@newsnipple.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
3 siblings, 2 replies; 27+ messages in thread
From: Adam Haberlach @ 2000-12-28 01:58 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>; pgsql-interfaces
On Wed, Dec 27, 2000 at 12:56:26AM -0500, Bruce Momjian wrote:
> I have been asked by the major PHP developer Rasmus Lerdorf to see if
> the PostgreSQL/PHP interface needs any improvements.
>
> Is the current PostgreSQL interface module in PHP adequate? Does it
> support all the current libpq features?
>
> If not, would someone submit some patches to the PHP folks. They want
> us to work well with PHP. They are basically encouraging us to improve
> it in any way we can.
I use PHP and Postgres together quite a bit, and find the APIs
complete enough for most things. However, just last week I implemented
pg_lolseek($loid, $offset $whence)
and
pg_lotell($loid)
For some stuff that we are working on. They are pretty straightforward,
and I can package them up and submit them if someone wants.
--
Adam Haberlach |A cat spends her life conflicted between a
adam@newsnipple.com |deep, passionate, and profound desire for
http://www.newsnipple.com |fish and an equally deep, passionate, and
'88 EX500 |profound desire to avoid getting wet.
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: PHP and PostgreSQL
@ 2001-01-02 03:56 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Adam Haberlach <adam@newsnipple.com>
1 sibling, 0 replies; 27+ messages in thread
From: Bruce Momjian @ 2001-01-02 03:56 UTC (permalink / raw)
To: Adam Haberlach <adam@newsnipple.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
Yes, please send them over to the PHP folks. Thanks.
> On Wed, Dec 27, 2000 at 12:56:26AM -0500, Bruce Momjian wrote:
> > I have been asked by the major PHP developer Rasmus Lerdorf to see if
> > the PostgreSQL/PHP interface needs any improvements.
> >
> > Is the current PostgreSQL interface module in PHP adequate? Does it
> > support all the current libpq features?
> >
> > If not, would someone submit some patches to the PHP folks. They want
> > us to work well with PHP. They are basically encouraging us to improve
> > it in any way we can.
>
> I use PHP and Postgres together quite a bit, and find the APIs
> complete enough for most things. However, just last week I implemented
>
> pg_lolseek($loid, $offset $whence)
> and
> pg_lotell($loid)
>
> For some stuff that we are working on. They are pretty straightforward,
> and I can package them up and submit them if someone wants.
>
> --
> Adam Haberlach |A cat spends her life conflicted between a
> adam@newsnipple.com |deep, passionate, and profound desire for
> http://www.newsnipple.com |fish and an equally deep, passionate, and
> '88 EX500 |profound desire to avoid getting wet.
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: PHP and PostgreSQL
@ 2001-01-02 03:57 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Rod Taylor <rbt@zort.on.ca>
0 siblings, 2 replies; 27+ messages in thread
From: Bruce Momjian @ 2001-01-02 03:57 UTC (permalink / raw)
To: Rod Taylor <rbt@zort.on.ca>; +Cc: pgsql-hackers@postgresql.org
This is interesting. I always wondered how the persistent connection
stuff handled this, and not I see that it doesn't.
[ Charset ISO-8859-1 unsupported, converting... ]
> > The only problem we have run into (and I have heard of others having this
> > problem also) is with persistent connections. I have seen discussion on
> > persistent connection problems but I'm not sure the problem was ever
> > resolved. The problem we have seen is that when using persistent
> > connections the web server doesn't seen to reuse the connections or
> somthing
> > to that effect. The result being that we eventually use up our postgres
> > limit of 48 connections and nothing can connect to postgre anymore. It is
> > possible that this is a configuration problem that we haven't sufficiently
> > investigated, but I meniton it because I have heard other talk of this.
> > Anyone have more information?
>
> The *real* problem with persistent connections is:
>
> Script1: BEGIN;
> Script1: UPDATE table set row = 'things';
> Script2: Insert into table (id) values ('bad data');
> Script1: COMMIT;
>
> Since script2 managed to do a BAD insert in the middle of script1's
> transaction, the transaction in script1 fails. Obvious solution? Don't do
> connection sharing when a transaction is enabled. The whole persistent
> connection thing is only valid for mysql as it's the only thing that doesn't
> really support transactions (and even thats partially changed).
>
> They need to look for stuff going through (keywords like BEGIN) and 'lock'
> that connection to the single entity that opened it.
>
> It's much easier to write your own. I wrote a few functions like:
>
> get_connection('DB PARMS');
> begin_transaction();
>
> commit_transaction();
> close_connection();
>
> All of this is done in a class which has knowledge of all connections that a
> script is currently using. Beginning a transaction locks down the
> connection from use by any other handler, they're all bumped to another one.
> Problem? It requires atleast 1 connection per page, but since they're
> actually dropped at close it's not so bad.
>
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 27+ messages in thread
* RE: PHP and PostgreSQL
@ 2001-01-02 03:59 Christopher Kings-Lynne <chriskl@familyhealth.com.au>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
1 sibling, 1 reply; 27+ messages in thread
From: Christopher Kings-Lynne @ 2001-01-02 03:59 UTC (permalink / raw)
To: pgsql-hackers@postgresql.org
At my work we were happily cruising along using PHP/Postgres persistent
connections. This was all happy until we installed Phorum. Phorum has its
own database abstraction layer, quite separate to all our own database
classes.
Now what happens is if someone browses the phorums for a little while, and
then switches to pages that use our own db classes, you get random slowdowns
(ie. a select occurs, and then times out after 2 mins or so).
If you use psql, and perform the select you get a 'shared memory corruption'
and 'timed out waiting for lock' errors.
Our basic theory is that somehow locks aren't being properly released by
phorum, or the connection pooling is stuffed - although Phorum doesn't use
the LOCK or BEGIN/COMMIT commands. Actually, we did notice that Phorum
issues a COMMIT whenever it closes a connection, even tho it never issues a
BEGIN. If we avoid running any Phorum scripts - no problems occur.
In an attempt to fix the problem, we configured phplib and Phorum to use
non-persistent postgresql connections. This worked fine, until now we have
a particular script, no different to the rest, that cannot acquire a
connection - it just gets an invalid resource handle. We switched phplib
back to persistent connections, and it works fine again - nothing else was
changed!
So my advice to the PHP people is to just fix Postgres connection handling!
Chris
> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Bruce Momjian
> Sent: Tuesday, January 02, 2001 11:58 AM
> To: Rod Taylor
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] PHP and PostgreSQL
>
>
> This is interesting. I always wondered how the persistent connection
> stuff handled this, and not I see that it doesn't.
>
> [ Charset ISO-8859-1 unsupported, converting... ]
> > > The only problem we have run into (and I have heard of others
> having this
> > > problem also) is with persistent connections. I have seen
> discussion on
> > > persistent connection problems but I'm not sure the problem was ever
> > > resolved. The problem we have seen is that when using persistent
> > > connections the web server doesn't seen to reuse the connections or
> > somthing
> > > to that effect. The result being that we eventually use up
> our postgres
> > > limit of 48 connections and nothing can connect to postgre
> anymore. It is
> > > possible that this is a configuration problem that we haven't
> sufficiently
> > > investigated, but I meniton it because I have heard other
> talk of this.
> > > Anyone have more information?
> >
> > The *real* problem with persistent connections is:
> >
> > Script1: BEGIN;
> > Script1: UPDATE table set row = 'things';
> > Script2: Insert into table (id) values ('bad data');
> > Script1: COMMIT;
> >
> > Since script2 managed to do a BAD insert in the middle of script1's
> > transaction, the transaction in script1 fails. Obvious
> solution? Don't do
> > connection sharing when a transaction is enabled. The whole persistent
> > connection thing is only valid for mysql as it's the only thing
> that doesn't
> > really support transactions (and even thats partially changed).
> >
> > They need to look for stuff going through (keywords like BEGIN)
> and 'lock'
> > that connection to the single entity that opened it.
> >
> > It's much easier to write your own. I wrote a few functions like:
> >
> > get_connection('DB PARMS');
> > begin_transaction();
> >
> > commit_transaction();
> > close_connection();
> >
> > All of this is done in a class which has knowledge of all
> connections that a
> > script is currently using. Beginning a transaction locks down the
> > connection from use by any other handler, they're all bumped to
> another one.
> > Problem? It requires atleast 1 connection per page, but since they're
> > actually dropped at close it's not so bad.
> >
> >
>
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: PHP and PostgreSQL
@ 2001-01-02 04:08 Rod Taylor <rbt@zort.on.ca>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
1 sibling, 0 replies; 27+ messages in thread
From: Rod Taylor @ 2001-01-02 04:08 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: pgsql-hackers@postgresql.org
It was obviously designed with MySQL's "Nobody needs transactions for
webwork" type of situation in mind.
> This is interesting. I always wondered how the persistent connection
> stuff handled this, and not I see that it doesn't.
>
> [ Charset ISO-8859-1 unsupported, converting... ]
> > > The only problem we have run into (and I have heard of others having
this
> > > problem also) is with persistent connections. I have seen discussion
on
> > > persistent connection problems but I'm not sure the problem was ever
> > > resolved. The problem we have seen is that when using persistent
> > > connections the web server doesn't seen to reuse the connections or
> > somthing
> > > to that effect. The result being that we eventually use up our
postgres
> > > limit of 48 connections and nothing can connect to postgre anymore.
It is
> > > possible that this is a configuration problem that we haven't
sufficiently
> > > investigated, but I meniton it because I have heard other talk of
this.
> > > Anyone have more information?
> >
> > The *real* problem with persistent connections is:
> >
> > Script1: BEGIN;
> > Script1: UPDATE table set row = 'things';
> > Script2: Insert into table (id) values ('bad data');
> > Script1: COMMIT;
> >
> > Since script2 managed to do a BAD insert in the middle of script1's
> > transaction, the transaction in script1 fails. Obvious solution? Don't
do
> > connection sharing when a transaction is enabled. The whole persistent
> > connection thing is only valid for mysql as it's the only thing that
doesn't
> > really support transactions (and even thats partially changed).
> >
> > They need to look for stuff going through (keywords like BEGIN) and
'lock'
> > that connection to the single entity that opened it.
> >
> > It's much easier to write your own. I wrote a few functions like:
> >
> > get_connection('DB PARMS');
> > begin_transaction();
> >
> > commit_transaction();
> > close_connection();
> >
> > All of this is done in a class which has knowledge of all connections
that a
> > script is currently using. Beginning a transaction locks down the
> > connection from use by any other handler, they're all bumped to another
one.
> > Problem? It requires atleast 1 connection per page, but since they're
> > actually dropped at close it's not so bad.
> >
> >
>
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: PHP and PostgreSQL
@ 2001-01-02 04:59 Tom Lane <tgl@sss.pgh.pa.us>
parent: Christopher Kings-Lynne <chriskl@familyhealth.com.au>
0 siblings, 0 replies; 27+ messages in thread
From: Tom Lane @ 2001-01-02 04:59 UTC (permalink / raw)
To: Christopher Kings-Lynne <chriskl@familyhealth.com.au>; +Cc: pgsql-hackers@postgresql.org
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Now what happens is if someone browses the phorums for a little while, and
> then switches to pages that use our own db classes, you get random slowdowns
> (ie. a select occurs, and then times out after 2 mins or so).
> If you use psql, and perform the select you get a 'shared memory corruption'
> and 'timed out waiting for lock' errors.
Ugh. We would like to think that client misbehavior couldn't cause such
things. Can you dig into this some more, and provide further details on
what is happening and what the sequence of client requests is?
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: PHP and PostgreSQL
@ 2001-01-02 07:16 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Karl DeBisschop <karl@debisschop.net>
0 siblings, 1 reply; 27+ messages in thread
From: Bruce Momjian @ 2001-01-02 07:16 UTC (permalink / raw)
To: Karl DeBisschop <karl@debisschop.net>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
Does this requested chagne have to do with Apache or PostgreSQL?
w wrote:
> >
> > I have been asked by the major PHP developer Rasmus Lerdorf to see
> > if
> > the PostgreSQL/PHP interface needs any improvements.
> >
> > Is the current PostgreSQL interface module in PHP adequate? Does it
> > support all the current libpq features?
> >
> > The only problem we have run into (and I have heard of others having this
> > problem also) is with persistent connections. I have seen discussion on
> > persistent connection problems but I'm not sure the problem was ever
> > resolved. The problem we have seen is that when using persistent
> > connections the web server doesn't seen to reuse the connections or somthing
> > to that effect. The result being that we eventually use up our postgres
> > limit of 48 connections and nothing can connect to postgre anymore. It is
> > possible that this is a configuration problem that we haven't sufficiently
> > investigated, but I meniton it because I have heard other talk of this.
> > Anyone have more information?
>
> Persistent connections behave exactly as advertised. Each apache process
> sets up and maintains persistent connections as needed. The problem is
> that for a typical web server, there are so many subprocesses that
> persistent connections are probably consume more resources than they
> save, unless they are combined with connection pooling across ALL the
> apache processes.
>
> Implementation of connection pooling is by far the most serious
> shortcoming of the current implementation, IMHO.
>
> I would dearly love to see this addressed as our postgresql database
> sees connections from about 300 servers for 6 databases. Since our
> postgresql server cannot support 1800 simultaneous active backends,
> persistent connections are useless without pooling. So instead we
> initiate 10 or more backends every second for generally very simple
> queries. Most of the queries are pretty simple, so I would not be at all
> surprised if we sent more system resources opening connections than we
> do actually answering queries
>
> --
> Karl DeBisschop kdebisschop@alert.infoplease.com
> Learning Network/Information Please http://www.infoplease.com
> Netsaint Plugin Developer kdebisschop@users.sourceforge.net
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: PHP and PostgreSQL
@ 2001-01-02 13:31 mlw <markw@mohawksoft.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 27+ messages in thread
From: mlw @ 2001-01-02 13:31 UTC (permalink / raw)
To: ; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
Bruce Momjian wrote:
>
> Does this requested chagne have to do with Apache or PostgreSQL?
>
I suspect it is a request that live postgresql processes can linger
around after a connection is completed and be re-assigned to a new
connection as soon as one comes along. This will save the startup cost
of a new postgresql process. This is what apache does.
--
http://www.mohawksoft.com
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: PHP and PostgreSQL
@ 2001-01-03 04:32 Tom Samplonius <tom@sdf.com>
parent: mlw <markw@mohawksoft.com>
0 siblings, 1 reply; 27+ messages in thread
From: Tom Samplonius @ 2001-01-03 04:32 UTC (permalink / raw)
To: mlw <markw@mohawksoft.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
On Tue, 2 Jan 2001, mlw wrote:
> Bruce Momjian wrote:
> >
> > Does this requested chagne have to do with Apache or PostgreSQL?
> >
> I suspect it is a request that live postgresql processes can linger
> around after a connection is completed and be re-assigned to a new
> connection as soon as one comes along. This will save the startup cost
> of a new postgresql process. This is what apache does.
I don't think is really going to provide much of an impact. Postgres
has to do a lot more initialization per session than Apache. Mainly
because Postgres has to deal with a stateful protocol, not a stateless one
like Apache. Besides, as already has been tested, session startup time is
minimal.
> --
> http://www.mohawksoft.com
Tom
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: PHP and PostgreSQL
@ 2001-01-03 06:07 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Samplonius <tom@sdf.com>
0 siblings, 1 reply; 27+ messages in thread
From: Tom Lane @ 2001-01-03 06:07 UTC (permalink / raw)
To: Tom Samplonius <tom@sdf.com>; +Cc: mlw <markw@mohawksoft.com>; PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
Tom Samplonius <tom@sdf.com> writes:
> ... Besides, as already has been tested, session startup time is
> minimal.
Well, mumble ...
I think the startup time is negligible if you are issuing a reasonable
number of queries per session (say a few dozen). But if you connect,
issue one query, and disconnect, then undoubtedly you will find that
performance sucks.
We could probably do more to improve this situation on the server side,
but IMHO it makes most sense to address the issue on the client side
via connection reuse. The main reason for this is that a significant
amount of the startup time for a standard connection consists of
authentication overhead and context setup overhead (such as setting the
timezone and character set encoding that the client wants to use).
A general-purpose connection-reuse facility on the server end cannot
eliminate these overheads, whereas it's trivial to avoid them within
the context of a multi-threaded client.
Bottom line: better to solve it by fixing Apache or PHP.
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: PHP and PostgreSQL
@ 2001-01-03 13:44 Frank Joerdens <frank@joerdens.de>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 27+ messages in thread
From: Frank Joerdens @ 2001-01-03 13:44 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Tom Samplonius <tom@sdf.com>; mlw <markw@mohawksoft.com>; PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
Tom Lane wrote:
[ . . . ]
> A general-purpose connection-reuse facility on the server end cannot
> eliminate these overheads, whereas it's trivial to avoid them within
> the context of a multi-threaded client.
PHP 4.04 does provide support for AOLServer now (which is multithreaded). I haven't had
time to play with it, and it moreover isn't certified for production use yet:
---------------------------------- snip ----------------------------------
NOTE: You should not use this module in production. PHP is not 100% stable
yet in threaded mode. To increase reliability enable the Global Lock
by removing #define NO_GLOBAL_LOCK in main/main.c. Also don't use
php_value as it will lead to races in a sub-system (use an ini file
instead).
---------------------------------- snap ----------------------------------
(from the php/sapi/aolserver/README)
But it might be the way to go forward with the connection pooling issue. Maybe the PHP
people could use some help from the Postgres developers there? I think it has been pointed
out in the context of this thread that Apache, as a multi-process server, could not
properly handle connection pooling because it's not feasible to pool connections across
several Apache children (or was that the problem?).
Regards, Frank
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: PHP and PostgreSQL
@ 2001-01-23 04:55 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Adam Haberlach <adam@newsnipple.com>
1 sibling, 1 reply; 27+ messages in thread
From: Bruce Momjian @ 2001-01-23 04:55 UTC (permalink / raw)
To: Adam Haberlach <adam@newsnipple.com>; +Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
Would to send this over to the PHP folks for inclusion? Thanks.
> On Wed, Dec 27, 2000 at 12:56:26AM -0500, Bruce Momjian wrote:
> > I have been asked by the major PHP developer Rasmus Lerdorf to see if
> > the PostgreSQL/PHP interface needs any improvements.
> >
> > Is the current PostgreSQL interface module in PHP adequate? Does it
> > support all the current libpq features?
> >
> > If not, would someone submit some patches to the PHP folks. They want
> > us to work well with PHP. They are basically encouraging us to improve
> > it in any way we can.
>
> I use PHP and Postgres together quite a bit, and find the APIs
> complete enough for most things. However, just last week I implemented
>
> pg_lolseek($loid, $offset $whence)
> and
> pg_lotell($loid)
>
> For some stuff that we are working on. They are pretty straightforward,
> and I can package them up and submit them if someone wants.
>
> --
> Adam Haberlach |A cat spends her life conflicted between a
> adam@newsnipple.com |deep, passionate, and profound desire for
> http://www.newsnipple.com |fish and an equally deep, passionate, and
> '88 EX500 |profound desire to avoid getting wet.
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: PHP and PostgreSQL
@ 2001-01-23 18:09 Adam Haberlach <adam@newsnipple.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 0 replies; 27+ messages in thread
From: Adam Haberlach @ 2001-01-23 18:09 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Adam Haberlach <adam@newsnipple.com>; PostgreSQL-development <pgsql-hackers@postgresql.org>; pgsql-interfaces
On Mon, Jan 22, 2001 at 11:55:56PM -0500, Bruce Momjian wrote:
> > On Wed, Dec 27, 2000 at 12:56:26AM -0500, Bruce Momjian wrote:
> > > I have been asked by the major PHP developer Rasmus Lerdorf to see if
> > > the PostgreSQL/PHP interface needs any improvements.
> > >
> > > Is the current PostgreSQL interface module in PHP adequate? Does it
> > > support all the current libpq features?
> > >
> > > If not, would someone submit some patches to the PHP folks. They want
> > > us to work well with PHP. They are basically encouraging us to improve
> > > it in any way we can.
> >
> > I use PHP and Postgres together quite a bit, and find the APIs
> > complete enough for most things. However, just last week I implemented
> >
> > pg_lolseek($loid, $offset $whence)
> > and
> > pg_lotell($loid)
> >
> > For some stuff that we are working on. They are pretty straightforward,
> > and I can package them up and submit them if someone wants.
> >
> Would to send this over to the PHP folks for inclusion? Thanks.
I sent them patches against the at-the-time up-to-date CVS tree back
when this first came up, they said that they failed, so I sent them another
set, and have not heard back from them. It doesn't seem to show up in the
cvs logs.
I'll bug someone again and see if I can find out what happened. I mean,
they only have 240 people with write access to the cvs tree...
--
Adam Haberlach |A cat spends her life conflicted between a
adam@newsnipple.com |deep, passionate, and profound desire for
http://www.newsnipple.com |fish and an equally deep, passionate, and
'88 EX500 |profound desire to avoid getting wet.
^ permalink raw reply [nested|flat] 27+ messages in thread
end of thread, other threads:[~2001-01-23 18:09 UTC | newest]
Thread overview: 27+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2000-12-27 05:56 PHP and PostgreSQL Bruce Momjian <pgman@candle.pha.pa.us>
2000-12-27 13:46 ` mlw <markw@mohawksoft.com>
2000-12-27 14:39 ` Daniele Orlandi <daniele@orlandi.com>
2000-12-27 16:24 ` Adam Lang <aalang@rutgersinsurance.com>
2000-12-27 17:03 ` Frank Joerdens <frank@joerdens.de>
2000-12-27 18:46 ` Adam Lang <aalang@rutgersinsurance.com>
2000-12-27 22:22 ` Frank Joerdens <frank@joerdens.de>
2000-12-27 21:30 ` Adam Lang <aalang@rutgersinsurance.com>
2000-12-27 22:22 ` Frank Joerdens <frank@joerdens.de>
2000-12-28 01:58 ` Adam Haberlach <adam@newsnipple.com>
2001-01-02 03:56 ` Bruce Momjian <pgman@candle.pha.pa.us>
2001-01-23 04:55 ` Bruce Momjian <pgman@candle.pha.pa.us>
2001-01-23 18:09 ` Adam Haberlach <adam@newsnipple.com>
2000-12-27 13:54 RE: [HACKERS] PHP and PostgreSQL Matthew <matt@ctlno.com>
2000-12-27 14:14 ` Adam Lang <aalang@rutgersinsurance.com>
2000-12-27 15:09 ` Rod Taylor <rbt@zort.on.ca>
2001-01-02 03:57 ` Bruce Momjian <pgman@candle.pha.pa.us>
2001-01-02 03:59 ` Christopher Kings-Lynne <chriskl@familyhealth.com.au>
2001-01-02 04:59 ` Tom Lane <tgl@sss.pgh.pa.us>
2001-01-02 04:08 ` Rod Taylor <rbt@zort.on.ca>
2000-12-27 15:15 ` mlw <markw@mohawksoft.com>
2000-12-27 16:45 ` Karl DeBisschop <karl@debisschop.net>
2001-01-02 07:16 ` Bruce Momjian <pgman@candle.pha.pa.us>
2001-01-02 13:31 ` mlw <markw@mohawksoft.com>
2001-01-03 04:32 ` Tom Samplonius <tom@sdf.com>
2001-01-03 06:07 ` Tom Lane <tgl@sss.pgh.pa.us>
2001-01-03 13:44 ` Frank Joerdens <frank@joerdens.de>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox