Обсуждение: JDBC driver GREATLY speeded up by trivial fix
First, sorry if this has been discussed before---I'm working with
the JDBC driver from the Postgresql 7.0 distribution.
I recently had occasion to run a profiler over an app, and
discovered that it was spending a lot of its time at the following
line in org.postgresql.PG_Stream.ReceiveString:
byte[] rst = new byte[maxsiz];
The point is that maxsiz is typically 8192, while the number of bytes
actually read into the buffer is the length of a field name
(i.e. never more than about 20). The resulting performance hit is
absolutely horrendous---the fact that the poor JVM has to
zero-initialise the array is bad enough, but think of the effect on
the CPU cache and the garbage collector!
My replacement for this routine is given below. It's not obviously
the fastest possible implementation, but the effect on the performance
of database-intensive applications is just _unreal_: I mean integer
factors, rather than a few percent.
I don't want to diss the efforts of the drivers' authors, but I
couldn't help noticing a few other horrors lurking around, like in
ResultSet.getDate and .getTimestamp both doing new SimpleDateFormat
every time they are called, which is pretty expensive if you look at
Sun's sources. [Incidentally .getTimestamp is broken by the 7.0
backend ...] Is it being actively maintained? Can I help?
Best wishes,
William
private static final class FinalByteArrayOutputStream extends ByteArrayOutputStream { public
FinalByteArrayOutputStream(intsize) { super(size); } } /** * Receives a null-terminated string from the
backend. Maximum of * maxsiz bytes - if we don't see a null, then we assume something * has gone wrong. * * @param
maxsizmaximum length of string * @return string from back end * @exception SQLException if an I/O error occurs */
public String ReceiveString(int maxsiz) throws SQLException { FinalByteArrayOutputStream buf = new
FinalByteArrayOutputStream(20);
try { for (;;) { if (buf.size() >= maxsiz) throw new PSQLException("postgresql.stream.toomuch");
int c = pg_input.read(); if (c < 0) throw new PSQLException("postgresql.stream.eof"); else
if(c == 0) break; else buf.write(c); } } catch (IOException e) { throw new
PSQLException("postgresql.stream.ioerror",e); }
return buf.toString(0); }
I am trying to create a database which will eventually become part of a dynamic Web page put up by AOLserver within .adp pages. This is all running on Linux 6.2 on a machine with 64 meg of RAM and plenty of disk.etc/rc/d/init. I can access it with the command psql <databasename>, which is nice, but PGAccess, the GUI, refuses to open it. The open command gives me the error message "Connection to database failed connect DBStart() -- connect() failed: network is unreachable Is the postmaster running (with -i) at "localhost" and accepting connections on TCP/IP port '5432'?" I do not know whther I am running the postmaster with -i. I started it with the command /etc/rc.d/init.d/postgresql start. I have also tried start -i. In both cases I get the response that postmaster is running -- which is why psql works. Netscape is refused by http://127.0.0.1 and by http://127.0.0.1:5432. What should I be doing about this "network is unreachable" or the "DBStart() -- connect failed"? Many thanks, -dlj.
"David Lloyd-Jones" <david.lloyd-jones@attcanada.ca> writes:
> PGAccess, the GUI, refuses to open it. The open command gives me the error
> message "Connection to database failed connect DBStart() -- connect()
> failed: network is unreachable ^^^^^^^^^^^^^^^^^^^^^^
Your networking configuration is broken: the kernel does not believe it
can contact itself. I can't give you much help about specific fixes,
but until you can do local loopback (such as "telnet 127.0.0.1") you
won't have any luck contacting the postmaster via TCP --- which is
what PGAccess wants to do.
I'd suggest reading some basic networking HOWTOs ...
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes
> "David Lloyd-Jones" <david.lloyd-jones@attcanada.ca> writes:
> > PGAccess, the GUI, refuses to open it. The open command gives me the
error
> > message "Connection to database failed connect DBStart() -- connect()
> > failed: network is unreachable
> ^^^^^^^^^^^^^^^^^^^^^^
> Your networking configuration is broken: the kernel does not believe it
> can contact itself. I can't give you much help about specific fixes,
> but until you can do local loopback (such as "telnet 127.0.0.1") you
> won't have any luck contacting the postmaster via TCP --- which is
> what PGAccess wants to do.
>
> I'd suggest reading some basic networking HOWTOs ...
>
Tom,
Thanks for your note. Not to be ungracious, (RTFM would always be good
advice, were it not for the fact that manuals are written at greater speed
than one can read them) but I don't see how this adds up: I'm not on a
network, and PSQL, which is a front end to PostgreSQL, just like PGAccess is
supposed to be, is running fine.
Let me rephrase the question this way: since PSQL works, why wouldn't
PGAccess?
Cheers,
-dlj.
"David Lloyd-Jones" <david.lloyd-jones@attcanada.ca> writes:
> than one can read them) but I don't see how this adds up: I'm not on a
> network, and PSQL, which is a front end to PostgreSQL, just like PGAccess is
> supposed to be, is running fine.
By default, psql connects via a Unix-socket path, not by TCP. PGAccess
is written differently and always tries to connect by TCP. If you try
to start psql with "-h localhost" or some such, it will try TCP and
fail in the same way ...
regards, tom lane
It looks like you don't have the user permission set up properly. Here is a jpg much like what you have descrbibed in the message. What the postmaster is not running in the background or the user permission is not set properly, you get a message like that. use the createuser command to create user and set proper permision and connect the db like. Philip Tom Lane wrote: > > "David Lloyd-Jones" <david.lloyd-jones@attcanada.ca> writes: > > than one can read them) but I don't see how this adds up: I'm not on a > > network, and PSQL, which is a front end to PostgreSQL, just like PGAccess is > > supposed to be, is running fine. > > By default, psql connects via a Unix-socket path, not by TCP. PGAccess > is written differently and always tries to connect by TCP. If you try > to start psql with "-h localhost" or some such, it will try TCP and > fail in the same way ... > > regards, tom lane
Вложения
Red Pineseed wrote: > > It looks like you don't have the user permission set up > properly. Here is a jpg much like what you have descrbibed > in the message. What the postmaster is not running in the > background or the user permission is not set properly, you > get a message like that. > > use the createuser command to create user and set proper > permision and connect the db like. > > Philip Except that there's a difference between "Connection refused", which is typical of the postmaster not being started with the -i option, and "Network unreachable", which is typical of a TCP/IP application where the kernel cannot resolve the route to the destination host. The user never did specify the success/failure of testing loop-back via telnet on 127.0.0.1. My bet is it didn't work. My money's on Tom Lane. Mike Mascari
"Red Pineseed" <yue207@home.com>. wrote:
> It looks like you don't have the user permission set up
> properly. Here is a jpg much like what you have descrbibed
> in the message. What the postmaster is not running in the
> background or the user permission is not set properly, you
> get a message like that.
>
> use the createuser command to create user and set proper
> permision and connect the db like.
Philip,
Thanks for your note. PostgreSQL starts with a default user named Postgres,
as far as I know. (Does anybody know its password? I've been assuming it's
either 'postgres' or null.)
Mike Mascari wrote:
Except that there's a difference between "Connection refused",
which is typical of the postmaster not being started with the -i
option, and "Network unreachable", which is typical of a TCP/IP
application where the kernel cannot resolve the route to the
destination host. The user never did specify the success/failure
of testing loop-back via telnet on 127.0.0.1. My bet is it didn't
work. My money's on Tom Lane.
Mike,
I did try the loopback, as I mentioned in a note to Tom (perhaps off-line,
sorry.)
Agreed, his explanation makes sense, and I'm looking for the right place to
put the -i.
Anybody know the innards of that /etc/rc.d/init.d/postgresql start
batchfile?
-dl
j.
David Lloyd-Jones wrote: > > I did try the loopback, as I mentioned in a note to Tom (perhaps off-line, > sorry.) > Agreed, his explanation makes sense, and I'm looking for the right place to > put the -i. > > Anybody know the innards of that /etc/rc.d/init.d/postgresql start > batchfile? The older RPMS started the postmaster without the -i for security reasons. However, the newer ones do start it up with TCP/IP support enabled by default. Which rpms are you using? You should look for a line like: su -l postgres -c '/usr/bin/postmaster -o -F -i -S -D/var/lib/pgsql' The -o -F flag combination turns off fsync. The -i switch will enable the TCP/IP connection. -S says to start up in silent mode. -D specifies the location of the where the data/base hierarchy is stored. If I recall the older RPMS correctly, they will have a line like: su -l postgres -c '/usr/bin/postmaster -S -D/var/lib/pgsql' So all you'll have to do is change it as it appears above with the -i switch (and I also recommend the -o -F pair as well). Hope that helps, Mike Mascari P.S.: If you are using the older RPMS with an older version of PostgreSQL (6.x), I highly recommend upgrading. Major bugs fixes and enhancements were made between the 6.x series and 7.x. Good Luck!
Tom Lane wrote: > > "David Lloyd-Jones" <david.lloyd-jones@attcanada.ca> writes: > > than one can read them) but I don't see how this adds up: I'm not on a > > network, and PSQL, which is a front end to PostgreSQL, just like PGAccess is > > supposed to be, is running fine. > > By default, psql connects via a Unix-socket path, not by TCP. PGAccess > is written differently and always tries to connect by TCP. If you try > to start psql with "-h localhost" or some such, it will try TCP and > fail in the same way ... BTW, is there a way to connect to PostgreSQL with libpgtcl with Unix-socket? Any parameters? In that case I can try changing PgAccess to connect in both ways! -- Constantin Teodorescu General Investment Group Braila, ROMANIA
Tom Lane wrote: >"David Lloyd-Jones" <david.lloyd-jones@attcanada.ca> writes: >> than one can read them) but I don't seehow this adds up: I'm not on a >> network, and PSQL, which is a front end to PostgreSQL, just like PGAccess >is >>supposed to be, is running fine. > >By default, psql connects via a Unix-socket path, not by TCP. PGAccess >is writtendifferently and always tries to connect by TCP. If you try >to start psql with "-h localhost" or some such, it willtry TCP and >fail in the same way ... If you leave blank the host field of pgaccess's connection dialog, it will use UNIX sockets instead of TCP/IP. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "Have not I commanded thee? Be strong and of a good courage; be not afraid,neither be thou dismayed; for the LORD thy God is with thee whithersoever thou goest." Joshua 1:9
Oliver:
Bingo!
Gratefully,
-dlj.
PS: More generally, I'd still like to know what to do with the script
"postgresql start" which is in subdirectory /etc/rc.d/init.d/ of RH 6.2.
There are lines that look somewhat like Mike Mascari's suggestions, but
nothing right on. Lamar Owen, are you out there somewhere?
-d.
----- Original Message -----
From: "Oliver Elphick" <olly@lfix.co.uk>
To: <pgsql-interfaces@postgresql.org>
Sent: Monday, July 31, 2000 1:53 AM
Subject: Re: [INTERFACES] PSQL Working, but PGAccess Not Connecting.
> Tom Lane wrote:
> >"David Lloyd-Jones" <david.lloyd-jones@attcanada.ca> writes:
> >> than one can read them) but I don't see how this adds up: I'm not on
a
> >> network, and PSQL, which is a front end to PostgreSQL, just like
PGAccess
> >is
> >> supposed to be, is running fine.
> >
> >By default, psql connects via a Unix-socket path, not by TCP. PGAccess
> >is written differently and always tries to connect by TCP. If you try
> >to start psql with "-h localhost" or some such, it will try TCP and
> >fail in the same way ...
>
> If you leave blank the host field of pgaccess's connection dialog, it will
> use UNIX sockets instead of TCP/IP.
>
> --
> Oliver Elphick Oliver.Elphick@lfix.co.uk
> Isle of Wight http://www.lfix.co.uk/oliver
> PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
> GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
> ========================================
> "Have not I commanded thee? Be strong and of a good
> courage; be not afraid, neither be thou dismayed; for
> the LORD thy God is with thee whithersoever thou
> goest." Joshua 1:9
>
>
>
The getTimestamp() problem has been discussed a lot on this list recently.
I'm currently having horrible problems with my home system (hasn't recovered
well after the move) so I've not been able to sit down and apply the fixes.
As for receiveString(), it predates the driver merger (some 2 years ago?) so
as it's never broke it's been left. I suspect there's a lot of little
performace gems in there if we had time to sit down and do them.
Peter
--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council
-----Original Message-----
From: William Chesters [mailto:williamc@paneris.org]
Sent: Sunday, July 30, 2000 5:21 PM
To: pgsql-interfaces@postgresql.org
Cc: melati_development@messageboards.paneris.org
Subject: [INTERFACES] JDBC driver GREATLY speeded up by trivial fix
First, sorry if this has been discussed before---I'm working with
the JDBC driver from the Postgresql 7.0 distribution.
I recently had occasion to run a profiler over an app, and
discovered that it was spending a lot of its time at the following
line in org.postgresql.PG_Stream.ReceiveString:
byte[] rst = new byte[maxsiz];
The point is that maxsiz is typically 8192, while the number of bytes
actually read into the buffer is the length of a field name
(i.e. never more than about 20). The resulting performance hit is
absolutely horrendous---the fact that the poor JVM has to
zero-initialise the array is bad enough, but think of the effect on
the CPU cache and the garbage collector!
My replacement for this routine is given below. It's not obviously
the fastest possible implementation, but the effect on the performance
of database-intensive applications is just _unreal_: I mean integer
factors, rather than a few percent.
I don't want to diss the efforts of the drivers' authors, but I
couldn't help noticing a few other horrors lurking around, like in
ResultSet.getDate and .getTimestamp both doing new SimpleDateFormat
every time they are called, which is pretty expensive if you look at
Sun's sources. [Incidentally .getTimestamp is broken by the 7.0
backend ...] Is it being actively maintained? Can I help?
Best wishes,
William
private static final class FinalByteArrayOutputStream extends ByteArrayOutputStream { public
FinalByteArrayOutputStream(intsize) { super(size); } } /** * Receives a null-terminated string from the
backend. Maximum of * maxsiz bytes - if we don't see a null, then we assume something * has gone wrong. * * @param
maxsizmaximum length of string * @return string from back end * @exception SQLException if an I/O error occurs */
public String ReceiveString(int maxsiz) throws SQLException { FinalByteArrayOutputStream buf = new
FinalByteArrayOutputStream(20);
try { for (;;) { if (buf.size() >= maxsiz) throw new PSQLException("postgresql.stream.toomuch");
int c = pg_input.read(); if (c < 0) throw new PSQLException("postgresql.stream.eof"); else
if(c == 0) break; else buf.write(c); } } catch (IOException e) { throw new
PSQLException("postgresql.stream.ioerror",e); }
return buf.toString(0); }
Peter Mount writes:> As for receiveString(), it predates the driver merger (some 2 years ago?) so> as it's never broke
it'sbeen left. I suspect there's a lot of little> performace gems in there if we had time to sit down and do them.
Well, nothing else really leaps out the profiling data. It looks like
the effect of further improvements will be relatively marginal
compared with the unavoidable time spent on socket reads/writes, and
of course waiting for the backend to do its stuff.
> I'm currently having horrible problems with my home system (hasn't recovered> well after the move)
sympathy ...
If you gave me a CVS p/w I could apply the ReceiveString fix and my
private fix for getTimestamp??
By the way, I've also got a rough implementation of
DatabaseMetaData.getIndexInfo---appended, with test harness---which
certainly does something, whether the JDBC-ly correct thing I don't
know!
Thanks,
William
public java.sql.ResultSet getIndexInfo(String catalog, String schema, String
table,boolean unique, boolean approximate) throws java.sql.SQLException {
return ((Connection)getConnection()).ExecSQL( "SELECT " + "null AS TABLE_CAT, null AS TABLE_SCHEMA,
t.relnameAS TABLE_NAME, " + "NOT i.indisunique AS NON_UNIQUE, null AS INDEX_QUALIFIER, " + "ti.relname
ASINDEX_NAME, " + tableIndexOther + " AS TYPE, " + "i.indkey[0] AS ORDINAL_POSITION, a.attname AS COLUMN_NAME,
"+ "NULL AS ASC_OR_DESC, 0 AS CARDINALITY, 0 AS PAGES, " + "NULL AS FILTER_CONDITION " + "FROM "
+ "pg_index i, pg_class ti, pg_class t, pg_attribute a " + "WHERE " + "ti.oid = i.indexrelid AND
t.oid= i.indrelid AND " + (table == null ? "" : "t.relname = '" +
StringUtils.escaped(table,'\'') + "' AND ") + (unique ? "i.indisunique AND " : "") + "a.attrelid =
i.indrelidAND " + // this strange little construct is needed because // `a.attnum = i.indkey[0]' causes
6.4.2(at least) to fail, losing // connection to backend: "a.attnum - i.indkey[0] = 0"); }
public static void main(String[] args) throws Exception {
java.sql.DriverManager.registerDriver((Driver)Class.forName("postgresql.Driver").newInstance()); java.sql.Connection c
=java.sql.DriverManager.getConnection("jdbc:postgresql:" + args[0], "postgres", "*"); java.sql.DatabaseMetaData m =
c.getMetaData();
java.sql.ResultSet inds = m.getIndexInfo(null, "", args[1], false, true); while (inds.next())
System.out.println("TABLE_CAT" + inds.getString("TABLE_CAT") + "\n" + "TABLE_SCHEMA " +
inds.getString("TABLE_SCHEMA")+ "\n" + "TABLE_NAME " + inds.getString("TABLE_NAME") + "\n" +
"NON_UNIQUE " + inds.getBoolean("NON_UNIQUE") + "\n" + "INDEX_QUALIFIER " +
inds.getString("INDEX_QUALIFIER")+ "\n" + "INDEX_NAME " + inds.getString("INDEX_NAME") + "\n" +
"TYPE " + inds.getShort("TYPE") + "\n" + "ORDINAL_POSITION " +
inds.getShort("ORDINAL_POSITION")+ "\n" + "COLUMN_NAME " + inds.getString("COLUMN_NAME") + "\n"
+ "ASC_OR_DESC " + inds.getString("ASC_OR_DESC") + "\n" + "CARDINALITY " +
inds.getInt("CARDINALITY")+ "\n" + "PAGES " + inds.getInt("PAGES") + "\n" +
"FILTER_CONDITION " + inds.getString("FILTER_CONDITION") + "\n"); }
You'll need to ask the hermit for CVS access ;-)
Peter
--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council
-----Original Message-----
From: William Chesters [mailto:williamc@paneris.org]
Sent: Monday, July 31, 2000 9:30 AM
To: pgsql-interfaces@postgresql.org;
melati_development@messageboards.paneris.org
Subject: RE: [INTERFACES] JDBC driver GREATLY speeded up by trivial fix
Peter Mount writes:> As for receiveString(), it predates the driver merger (some 2 years ago?)
so> as it's never broke it's been left. I suspect there's a lot of little> performace gems in there if we had time to
sitdown and do them.
Well, nothing else really leaps out the profiling data. It looks like
the effect of further improvements will be relatively marginal
compared with the unavoidable time spent on socket reads/writes, and
of course waiting for the backend to do its stuff.
> I'm currently having horrible problems with my home system (hasn't
recovered> well after the move)
sympathy ...
If you gave me a CVS p/w I could apply the ReceiveString fix and my
private fix for getTimestamp??
By the way, I've also got a rough implementation of
DatabaseMetaData.getIndexInfo---appended, with test harness---which
certainly does something, whether the JDBC-ly correct thing I don't
know!
Thanks,
William
public java.sql.ResultSet getIndexInfo(String catalog, String schema, String
table,boolean unique, boolean approximate) throws java.sql.SQLException {
return ((Connection)getConnection()).ExecSQL( "SELECT " + "null AS TABLE_CAT, null AS TABLE_SCHEMA,
t.relnameAS TABLE_NAME,
" + "NOT i.indisunique AS NON_UNIQUE, null AS INDEX_QUALIFIER, " + "ti.relname AS INDEX_NAME, " +
tableIndexOther+ " AS TYPE, " + "i.indkey[0] AS ORDINAL_POSITION, a.attname AS COLUMN_NAME, " + "NULL
ASASC_OR_DESC, 0 AS CARDINALITY, 0 AS PAGES, " + "NULL AS FILTER_CONDITION " + "FROM " +
"pg_indexi, pg_class ti, pg_class t, pg_attribute a " + "WHERE " + "ti.oid = i.indexrelid AND t.oid =
i.indrelidAND " + (table == null ? "" : "t.relname = '" + StringUtils.escaped(table,
'\'')+ "' AND ")
+ (unique ? "i.indisunique AND " : "") + "a.attrelid = i.indrelid AND " + // this strange
littleconstruct is needed because // `a.attnum = i.indkey[0]' causes 6.4.2 (at least) to fail,
losing // connection to backend: "a.attnum - i.indkey[0] = 0"); }
public static void main(String[] args) throws Exception {
java.sql.DriverManager.registerDriver((Driver)Class.forName("postgresql.Driv
er").newInstance()); java.sql.Connection c =
java.sql.DriverManager.getConnection("jdbc:postgresql:" + args[0],
"postgres", "*"); java.sql.DatabaseMetaData m = c.getMetaData();
java.sql.ResultSet inds = m.getIndexInfo(null, "", args[1], false,
true); while (inds.next()) System.out.println("TABLE_CAT " + inds.getString("TABLE_CAT") + "\n" +
"TABLE_SCHEMA " + inds.getString("TABLE_SCHEMA") +
"\n" + "TABLE_NAME " + inds.getString("TABLE_NAME") + "\n"
+ "NON_UNIQUE " + inds.getBoolean("NON_UNIQUE") +
"\n" + "INDEX_QUALIFIER " +
inds.getString("INDEX_QUALIFIER") + "\n" + "INDEX_NAME " + inds.getString("INDEX_NAME") + "\n"
+ "TYPE " + inds.getShort("TYPE") + "\n" + "ORDINAL_POSITION " +
inds.getShort("ORDINAL_POSITION") + "\n" + "COLUMN_NAME " + inds.getString("COLUMN_NAME") +
"\n" + "ASC_OR_DESC " + inds.getString("ASC_OR_DESC") +
"\n" + "CARDINALITY " + inds.getInt("CARDINALITY") + "\n"
+ "PAGES " + inds.getInt("PAGES") + "\n" + "FILTER_CONDITION " +
inds.getString("FILTER_CONDITION") + "\n"); }
On Mon, 31 Jul 2000, Oliver Elphick wrote: > If you leave blank the host field of pgaccess's connection dialog, it will > use UNIX sockets instead of TCP/IP. Is this documented anywhere? I think I read the docs, but have always been under the impression that pgaccess only used TCP/IP. And BTW, both methods work fine for me.. -Cedar
> PS: More generally, I'd still like to know what to do with the script
> "postgresql start" which is in subdirectory /etc/rc.d/init.d/ of RH 6.2.
> There are lines that look somewhat like Mike Mascari's suggestions, but
> nothing right on. Lamar Owen, are you out there somewhere?
That is intended to start up and shut down the Postgres server when your
system boot or halts. It needs a soft link in /etc/rc.d/rc3.d and /rc5.d
to actually get invoked automatically. I usually set it up as a "S99"
script, but Lamar may have a different convention for his RPMs.
What else do you need to know about it?
- Thomas
> If you gave me a CVS p/w I could apply the ReceiveString fix and my
> private fix for getTimestamp??
The usual procedure is to post the patches to the -patches mailing list
and someone will pick them up and apply them. Usually for JDBC stuff we
would wait for Peter to evaluate and apply them, but if he sez the
patches are appropriate then someone else will put them into the tree.
- Thomas
----- Original Message -----
From: "Thomas Lockhart" <lockhart@alumni.caltech.edu>
To: "David Lloyd-Jones" <david.lloyd-jones@attcanada.ca>
Cc: <pgsql-interfaces@postgresql.org>; "Oliver Elphick" <olly@lfix.co.uk>
Sent: Monday, July 31, 2000 10:58 AM
Subject: Re: [INTERFACES] PSQL Working, but PGAccess Not Connecting.
> > PS: More generally, I'd still like to know what to do with the script
> > "postgresql start" which is in subdirectory /etc/rc.d/init.d/ of RH
6.2.
> > There are lines that look somewhat like Mike Mascari's suggestions, but
> > nothing right on. Lamar Owen, are you out there somewhere?
>
> That is intended to start up and shut down the Postgres server when your
> system boot or halts. It needs a soft link in /etc/rc.d/rc3.d and /rc5.d
> to actually get invoked automatically. I usually set it up as a "S99"
> script, but Lamar may have a different convention for his RPMs.
>
> What else do you need to know about it?
>
Tom,
Do I want to add a "-i" somewhere inside it?
Or is there some other way of making the postmaster talk to "the network"?
If so, what would the command line be?
Many thanks,
-dlj.
> Do I want to add a "-i" somewhere inside it?
Sure, if it isn't there already. I haven't looked at the script
recently, but I recall that the predecessor had some commented-out lines
to illustrate where this kind of thing should occur.
Perhaps the "-i" is disabled by default to enhance out-of-the-box
network security?
- Thomas
Thomas Lockhart wrote: > > Do I want to add a "-i" somewhere inside it? > Sure, if it isn't there already. I haven't looked at the script > recently, but I recall that the predecessor had some commented-out lines > to illustrate where this kind of thing should occur. > Perhaps the "-i" is disabled by default to enhance out-of-the-box > network security? [I'm going to reply to this one rather than all the previous ones. Sorry for the delay in responding, but I just got back from a 'working' vacation, and had alot of front-burner items to handle before I could get on my notebook. And, last night I was going to get online, but a thunderstorm outbreak prevented me....] David, if you're running 6.5.3 that came with RH 6.2, there should already be a '-i' on the postmaster startup line in /etc/rc.d/init.d/postgresql. If, however, you're running 7.0.2, the whole startup has changed. Look in /var/lib/pgsql/data/postmaster.opts.default (IIRC) for a '-i' -- the 7.0.2 RPM's start postmaster through pgctl. If you not running 7.0.2, you really should investigate upgrading. AOLserver's performance takes a leap against 7 versus 6.5, for some reason that I've not been able to fathom. As to the network unreachable errors, you have a network configuration problem somewhere that is causing your machine to not work with TCP/IP, for some reason. The default startup in the RPM's has been, since 6.5.2 or so, to enable the -i -- and the reason -i wasn't enabled before wasn't so much security as it was the fact the no one bothered to add -i to the startup file after PostgreSQL 6.3 changed the default to require -i for TCP/IP connections. Also, if you have Apache installed, AOLserver will have serious trouble binding port 80 (even if Apache is not running). HTH -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
"Lamar Owen" <lamar.owen@wgcr.org> wrote:
>
> [I'm going to reply to this one ....]
>
> David, if you're running 6.5.3 that came with RH 6.2, there should
> already be a '-i' on the postmaster startup line in
> /etc/rc.d/init.d/postgresql. If, however, you're running 7.0.2, the
> whole startup has changed. Look in
> /var/lib/pgsql/data/postmaster.opts.default (IIRC) for a '-i' -- the
> 7.0.2 RPM's start postmaster through pgctl.
Lamar,
Many thanks. Yep, the -i is there as you say, and yes, 7.0.2 is what I'm
running.
So the quewstion becomes, How do I go looking for other causes?
And incidentally, how do I get rid of Apache to avoid the interfrence
problem on port 80 that you mention?
In case Lamar doesn't get this for a day or so, replies off-line from the
other people on the list will be welcome.
Cheers,
-dlj.
"Lamar Owen" <lamar.owen@wgcr.org> wrote:
>
> [I'm going to reply to this one ....]
>
In wondering, in my newbie way, why Postgresql wouldn't be outputting to
"the Net," i.e. to my own machine but in TCP/IP, I read over Owen's start-up
script "/etc/rc.d/init.d/postgresql start" to see that all the stuff
mentioned in it in fact exists. It seems to.
What is more puzzling is that the script even checks for whether or not
"$(NETWORKING)= "no" && exit 0" which sounds like it ought to be doing the
right thing. Yet PGAccess won't start, except with Oliver's cunning
workaround -- suggesting that postmaster is not running in Net mode.
How can this be? Isn't this a contradiction of some sort?
-dlj.
Roberto,
I've followed your install-from-source instructions from the OpenACS site,
and it went like a dream -- my first compile since school fifteen years
ago! -- right up untilthe testing section when I went looking for the NSD8X
and NSD76. Both missing.
(And I'm not clear from your instructions what I should be connecting to
what with the symbolic link.)
There is an nsd.tcl, and that's it. From any direcvtory your suggested
command, ./bin/nsd -kt nsd.tcl , gives nsd: no such command or directory.
I'm goijng to erase all this stuf for now, and see if I can run with the
binary. But if you get time, I wonder how I've messed up, or is it possible
that AOLserver3.0.tar.gz somehow comes without the nsd76 and nsd8x that
should be there?
Best wishes,
-dlj.