pgsql/src/interfaces/libpq fe-connect.c fe-exe ...h

pgsql/src/interfaces/libpq fe-connect.c fe-exe ...h

Post by Bruce Momji » Sun, 22 Jul 2001 06:28:34




> > Log message:
> >       i've spotted a following problem using DBD::Pg under win32. winsock
> >       functions do not set errno, so some normal conditions are treated as
> >       fatal errors. e.g. fetching large tuples fails, as at some point recv()
> >       returns EWOULDBLOCK. here's a patch, which replaces errno with
> >       WSAGetLastError(). i've tried to to affect non-win32 code.

> I thought this was awaiting a merged patch from both submitters?

> Certainly I haven't reviewed it, since I thought that we were not
> going to apply it until that happened.

The other maintainer said this patch was better.  He wants a few lines
of his patch added as well and he will send that over soon.  You want to
see the applied patch or have it backed out?

--
  Bruce Momjian                        |  http://candle.pha.pa.us

  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly

 
 
 

pgsql/src/interfaces/libpq fe-connect.c fe-exe ...h

Post by Bruce Momji » Sun, 22 Jul 2001 07:04:15



> >> I thought this was awaiting a merged patch from both submitters?

> > The other maintainer said this patch was better.

> Oh, I guess I missed that message.

It only came to me.  Sometimes I don't check to see the user told
everyone in the email.

Quote:> > He wants a few lines
> > of his patch added as well and he will send that over soon.  You want to
> > see the applied patch or have it backed out?

> No, I'll just look at the combined diff once both patches are in.

OK.  I was getting worried that no one was merging the patches in the
queue and then yesterday both people came through.

--
  Bruce Momjian                        |  http://candle.pha.pa.us

  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

---------------------------(end of broadcast)---------------------------


 
 
 

pgsql/src/interfaces/libpq fe-connect.c fe-exe ...h

Post by Tom La » Sun, 22 Jul 2001 07:04:15



>> I thought this was awaiting a merged patch from both submitters?
> The other maintainer said this patch was better.

Oh, I guess I missed that message.

Quote:> He wants a few lines
> of his patch added as well and he will send that over soon.  You want to
> see the applied patch or have it backed out?

No, I'll just look at the combined diff once both patches are in.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------

 
 
 

1. pgsql/src/interfaces/libpq (fe-connect.c libpq-fe.h libpq-int.h libpqdll.def)


Author: momjian

Update of /home/projects/pgsql/cvsroot/pgsql/src/interfaces/libpq
     from hub.org:/home/projects/pgsql/tmp/cvs-serv65584/pgsql/src/interfaces/libpq

Modified Files:
        fe-connect.c libpq-fe.h libpq-int.h libpqdll.def

-----------------------------  Log Message  -----------------------------

UUNET is looking into offering PostgreSQL as a part of a managed web
hosting product, on both shared and dedicated machines.  We currently
offer Oracle and MySQL, and it would be a nice middle-ground.
However, as shipped, PostgreSQL lacks the following features we need
that MySQL has:

1. The ability to listen only on a particular IP address.  Each
   hosting customer has their own IP address, on which all of their
   servers (http, ftp, real media, etc.) run.
2. The ability to place the Unix-domain socket in a mode 700 directory.
   This allows us to automatically create an empty database, with an
   empty DBA password, for new or upgrading customers without having
   to interactively set a DBA password and communicate it to (or from)
   the customer.  This in turn cuts down our install and upgrade times.
3. The ability to connect to the Unix-domain socket from within a
   change-rooted environment.  We run CGI programs chrooted to the
   user's home directory, which is another reason why we need to be
   able to specify where the Unix-domain socket is, instead of /tmp.
4. The ability to, if run as root, open a pid file in /var/run as
   root, and then setuid to the desired user.  (mysqld -u can almost
   do this; I had to patch it, too).

The patch below fixes problem 1-3.  I plan to address #4, also, but
haven't done so yet.  These diffs are big enough that they should give
the PG development team something to think about in the meantime :-)
Also, I'm about to leave for 2 weeks' vacation, so I thought I'd get
out what I have, which works (for the problems it tackles), now.

With these changes, we can set up and run PostgreSQL with scripts the
same way we can with apache or proftpd or mysql.

In summary, this patch makes the following enhancements:

1. Adds an environment variable PGUNIXSOCKET, analogous to MYSQL_UNIX_PORT,
   and command line options -k --unix-socket to the relevant programs.
2. Adds a -h option to postmaster to set the hostname or IP address to
   listen on instead of the default INADDR_ANY.
3. Extends some library interfaces to support the above.
4. Fixes a few memory leaks in PQconnectdb().

The default behavior is unchanged from stock 7.0.2; if you don't use
any of these new features, they don't change the operation.

David J. MacKenzie

2. FW: Diff between 9.21.UC3-1 and 9.21.HC3-1

3. pgsql/src/interfaces/libpq (fe-connect.c fe-exec.c)

4. Senior Project -- Data Warehouse

5. pgsql/src/interfaces/libpq fe-connect.c fe-misc.c

6. New DBOne2003 released

7. pgsql/src/interfaces/libpq fe-exec.c libpq-fe.h

8. Array in stored procedure

9. pgsql/src/interfaces/libpq fe-connect.c libpq- ...

10. pgsql/src/interfaces/libpq (fe-connect.c libpq-int.h)

11. pgsql/src/interfaces/libpq libpq-fe.h libpq-int.h

12. pgsql/src/interfaces/libpq (fe-connect.c)