hi,i want to start database which can accept tcp/ip connecttions,now
there is a question:
i start database with the command:
/usr/local/pgsql/bin/postmaster -o "-i" -D /usr/local/pgsql/data
and edit pg_hba.conf with adding the line :
host all all 127.0.0.1/32 trust
host rftDatabase globus 127.0.0.1 255.255.255.255 trust

and after that i cant use psql to connect the database,here is the message:
psql: FATAL: invalid command-line arguments for server process
HINT: Try "postgres --help" for more information.

but if i start with : /usr/local/pgsql/bin/postmaster -o -i -D
/usr/local/pgsql/data
then i can connet database psql command,
in two situation i cat connect database with the file:
String url="jdbcostgresql://xiaohua/rftDatabase";
String user = "globus";
String password = "globus";
try
{
Class.forName("org.postgresql.Driver");
System.out.println("9999999999");
}
catch(Exception ex)
{
System.out.println("Sub ------------: " + ex);
}

the error message is that:
Unable to connect======================
org.postgresql.util.PSQLException: Á¬½Ó³¢ÊÔʧ°Ü¡£
at org.postgresql.core.v3.ConnectionFactoryImpl.openC onnectionImpl(ConnectionFactoryImpl.java:136)
at org.postgresql.core.ConnectionFactory.openConnecti on(ConnectionFactory.java:65)
at org.postgresql.jdbc2.AbstractJdbc2Connection.(Abst ractJdbc2Connection.java:117)
at org.postgresql.jdbc3.AbstractJdbc3Connection.(Abst ractJdbc3Connection.java:30)
at org.postgresql.jdbc3.Jdbc3Connection.(Jdbc3Connect ion.java:24)
at org.postgresql.Driver.connect(Driver.java:235)
at java.sql.DriverManager.getConnection(DriverManager .java:512)
at java.sql.DriverManager.getConnection(DriverManager .java:171)
at TableDisplay.(TableDisplay.java:39)
at TableDisplay.main(TableDisplay.java:158)
Caused by: java.net.SocketException: Invalid argument or cannot assign
requested address
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl .java:305)
at java.net.PlainSocketImpl.connectToAddress(PlainSoc ketImpl.java:171)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.j ava:158)
at java.net.Socket.connect(Socket.java:452)
at java.net.Socket.connect(Socket.java:402)
at java.net.Socket.(Socket.java:309)
at java.net.Socket.(Socket.java:124)
at org.postgresql.core.PGStream.(PGStream.java:58)
at org.postgresql.core.v3.ConnectionFactoryImpl.openC onnectionImpl(ConnectionFactoryImpl.java:77)
.... 9 more
Exception in thread "main" java.lang.NullPointerException
at TableDisplay.getTable(TableDisplay.java:69)
at TableDisplay.(TableDisplay.java:55)
at TableDisplay.main(TableDisplay.java:158)

the jdbc driver is rightly confirmed and the classpath is right.
this question exists for few days and how should do next?thaks for
your attention!

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

=?GB2312?B?zfXP/ruq?= <jacob.xiaohua@gmail.com> writes:
> /usr/local/pgsql/bin/postmaster -o "-i" -D /usr/local/pgsql/data

That should be just
/usr/local/pgsql/bin/postmaster -i -D /usr/local/pgsql/data

You seem to be confusing pg_ctl syntax with postmaster syntax.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Thought that v8 started with default tcp availability.

G.

On 7/29/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> =?GB2312?B?zfXP/ruq?= <jacob.xiaohua@gmail.com> writes:
> > /usr/local/pgsql/bin/postmaster -o "-i" -D /usr/local/pgsql/data
>
> That should be just
> /usr/local/pgsql/bin/postmaster -i -D /usr/local/pgsql/data
>
> You seem to be confusing pg_ctl syntax with postmaster syntax.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>



--
"Adopting the position that you are smarter than an automatic
optimization algorithm is generally a good way to achieve less
performance, not more" - Tom Lane.

Guido Barosio wrote:
> Thought that v8 started with default tcp availability.

It is _enabled_ by default for connections, but local clients don't use
tcp by default.

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


>
> G.
>
> On 7/29/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > =?GB2312?B?zfXP/ruq?= <jacob.xiaohua@gmail.com> writes:
> > > /usr/local/pgsql/bin/postmaster -o "-i" -D /usr/local/pgsql/data
> >
> > That should be just
> > /usr/local/pgsql/bin/postmaster -i -D /usr/local/pgsql/data
> >
> > You seem to be confusing pg_ctl syntax with postmaster syntax.
> >
> > regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: don't forget to increase your free space map settings
> >
>
>
>
> --
> "Adopting the position that you are smarter than an automatic
> optimization algorithm is generally a good way to achieve less
> performance, not more" - Tom Lane.

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

All:

We have a postgres 7.4 server where we're trying to achieve some speedups.
Right now, at least superficially, RAM appears to be the bottleneck -- lots
of swaps in and out.

There is another consultant beside myself in the mix and he asked this
question: can we put the database indexes on a RAM disk? Won't that speed
things up?

My first instinct is NEVER NEVER NEVER to put any database data in volatile
storage like that. But on second thought, I thought I'd ask. Is this crazy?
If one did it, how would you handle repopulating the indexes if the RAM
disk were lost? Just have a shell script that would do that automatically?
Or will postgres 8 rebuild an index if it doesn't find it where it expects?

I recognize, or think I do, that PG 8 tablespaces would be required to
accomplish this.

Would this be insane? Has anyone done it?


--------
Steve Lane
Vice President
Soliant Consulting, Inc.
(312) 850-3830 (V)
(312) 850-3930 (F)
slane@soliantconsulting.com


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

> RAM appears to be the bottleneck -- lots
> of swaps in and out.
> can we put the database indexes on a RAM disk?

Can you increase the RAM in the machine? I guess I should assume you're
maxed out.

Rick
pgsql-admin-owner@postgresql.org wrote on 07/29/2005 10:32:28 AM:

> All:
>
> We have a postgres 7.4 server where we're trying to achieve some
speedups.
> Right now, at least superficially, RAM appears to be the bottleneck --
lots
> of swaps in and out.
>
> There is another consultant beside myself in the mix and he asked this
> question: can we put the database indexes on a RAM disk? Won't that speed
> things up?
>
> My first instinct is NEVER NEVER NEVER to put any database data in
volatile
> storage like that. But on second thought, I thought I'd ask. Is this
crazy?
> If one did it, how would you handle repopulating the indexes if the RAM
> disk were lost? Just have a shell script that would do that
automatically?
> Or will postgres 8 rebuild an index if it doesn't find it where it
expects?
>
> I recognize, or think I do, that PG 8 tablespaces would be required to
> accomplish this.
>
> Would this be insane? Has anyone done it?
>
>
> --------
> Steve Lane
> Vice President
> Soliant Consulting, Inc.
> (312) 850-3830 (V)
> (312) 850-3930 (F)
> slane@soliantconsulting.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Steve Lane <slane@soliantconsulting.com> writes:
> Or will postgres 8 rebuild an index if it doesn't find it where it expects?

No, but there's always REINDEX.

> I recognize, or think I do, that PG 8 tablespaces would be required to
> accomplish this.

It'd certainly make it a lot easier. Also, it's probably not worth the
pain to try to move system catalog indexes to RAMdisk --- that'll
greatly complicate the restart process. User-table indexes could be
fixed just with REINDEX.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Steve Lane wrote:

>All:
>
>We have a postgres 7.4 server where we're trying to achieve some speedups.
>Right now, at least superficially, RAM appears to be the bottleneck -- lots
>of swaps in and out.
>
>There is another consultant beside myself in the mix and he asked this
>question: can we put the database indexes on a RAM disk? Won't that speed
>things up?
>
>
I am quite wary about putting the indexes on a RAM DISK for another reason.

You say that RAM is your bottleneck, so putting anything unnecessary in
RAM seems like a good way to get less performance rather than more.
Additionally you have some overhead in tracking the files, etc. and they
will remain in RAM even when they are not used. This leaves the system
with less effective RAM for the memory intensive operations.

Such a move might make a lot of sense if you had a LOT of RAM but disk
I/O was the bottleneck. However, if a lack of RAM is your problem,
putting more stuff in RAM doesn't seem very sound to me.

Best Wishes,
Chris Travers
Metatron Technology Consulting

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

We're going to build a new server with a bit more RAM -- 8 gigs.

I know memory is somehow the bottleneck, but I don't think it's because I
have too little. Performance monitors show a lot of swap activity during
heavy query load testing, but available RAM is never maxed out, or even
close. SOMETHING is starved for RAM, I just don't know what.

We are running a web app here and have Apache and PG on the same box. I
have PG buffers set very high, about 100K. Data set approaches 3 gigs.

My gut feeling is I have RAM to spare, I'm just somehow not efficiently
using what I have.

I just wanted a gut-check reaction to this idea, and I don't hear anyone
saying "NO! NEVER!". What I'm hearing is that it might, or might not, be
practical, feasible, maintainable.

Thanks for the replies. I'll look more at the memory usage and see what
comes up.

-- sgl


> From: Chris Travers <chris@travelamericas.com>
> Date: Fri, 29 Jul 2005 09:50:07 -0700
> To: Steve Lane <slane@soliantconsulting.com>
> Cc: <pgsql-admin@postgresql.org>
> Subject: Re: [ADMIN] Indexes on RAM disk = insanity?
>
> Steve Lane wrote:
>
>> All:
>>
>> We have a postgres 7.4 server where we're trying to achieve some speedups.
>> Right now, at least superficially, RAM appears to be the bottleneck -- lots
>> of swaps in and out.
>>
>> There is another consultant beside myself in the mix and he asked this
>> question: can we put the database indexes on a RAM disk? Won't that speed
>> things up?
>>
>>
> I am quite wary about putting the indexes on a RAM DISK for another reason.
>
> You say that RAM is your bottleneck, so putting anything unnecessary in
> RAM seems like a good way to get less performance rather than more.
> Additionally you have some overhead in tracking the files, etc. and they
> will remain in RAM even when they are not used. This leaves the system
> with less effective RAM for the memory intensive operations.
>
> Such a move might make a lot of sense if you had a LOT of RAM but disk
> I/O was the bottleneck. However, if a lack of RAM is your problem,
> putting more stuff in RAM doesn't seem very sound to me.
>
> Best Wishes,
> Chris Travers
> Metatron Technology Consulting


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

If I could toss in my $0.02 ... We were provided a 2GB solid-state storage
device for testing purposes. Our initial idea was to put the WAL on it, which
we thought would greatly improve database performance. While it did help a bit,
it wasn't a gigantic performance gain.

What finally became the largest performance gain was to put the actual tables
and indexes on the device. We were using 7.4 at the time, so we symlinked the
files instread of using tablespaces. It was an incredible improvement.

Our only issue was that the database, in its entirety, is about 10 GB. You pay
roughtly $2K/gig for a solid state storage. Solid state storage is fantastic.
No moving parts, MTBF was way way longer than a mechanical drive, and it has
battery backup and a tiny mechanical drive to off-load the data onto in case of
a power failure.

It is a whole world of difference in stability compared to a ramdisk. Its
preformance is quite comparible. It is extremely expensive to impliment on a
large scale, so I'd spend my time trying to find out what's causing your
swap-outs. If indexes in RAM is your final solution, I'd consider the solid
state drive as your responsible solution...

CG

--- Steve Lane <slane@soliantconsulting.com> wrote:

> We're going to build a new server with a bit more RAM -- 8 gigs.
>
> I know memory is somehow the bottleneck, but I don't think it's because I
> have too little. Performance monitors show a lot of swap activity during
> heavy query load testing, but available RAM is never maxed out, or even
> close. SOMETHING is starved for RAM, I just don't know what.
>
> We are running a web app here and have Apache and PG on the same box. I
> have PG buffers set very high, about 100K. Data set approaches 3 gigs.
>
> My gut feeling is I have RAM to spare, I'm just somehow not efficiently
> using what I have.
>
> I just wanted a gut-check reaction to this idea, and I don't hear anyone
> saying "NO! NEVER!". What I'm hearing is that it might, or might not, be
> practical, feasible, maintainable.
>
> Thanks for the replies. I'll look more at the memory usage and see what
> comes up.
>
> -- sgl
>
>
> > From: Chris Travers <chris@travelamericas.com>
> > Date: Fri, 29 Jul 2005 09:50:07 -0700
> > To: Steve Lane <slane@soliantconsulting.com>
> > Cc: <pgsql-admin@postgresql.org>
> > Subject: Re: [ADMIN] Indexes on RAM disk = insanity?
> >
> > Steve Lane wrote:
> >
> >> All:
> >>
> >> We have a postgres 7.4 server where we're trying to achieve some speedups.
> >> Right now, at least superficially, RAM appears to be the bottleneck --
> lots
> >> of swaps in and out.
> >>
> >> There is another consultant beside myself in the mix and he asked this
> >> question: can we put the database indexes on a RAM disk? Won't that speed
> >> things up?
> >>
> >>
> > I am quite wary about putting the indexes on a RAM DISK for another reason.
> >
> > You say that RAM is your bottleneck, so putting anything unnecessary in
> > RAM seems like a good way to get less performance rather than more.
> > Additionally you have some overhead in tracking the files, etc. and they
> > will remain in RAM even when they are not used. This leaves the system
> > with less effective RAM for the memory intensive operations.
> >
> > Such a move might make a lot of sense if you had a LOT of RAM but disk
> > I/O was the bottleneck. However, if a lack of RAM is your problem,
> > putting more stuff in RAM doesn't seem very sound to me.
> >
> > Best Wishes,
> > Chris Travers
> > Metatron Technology Consulting
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly