admin wrote:
Sorry folks, a perennial one I'm sure ...
I have read the manual and Googled for a couple of hours but still can't
connect to PostgreSQL 8.3.4 (the PGDG RPMs running on an up to date
CentOS 5.2).
I continually get this message:
psql: could not connect to server: No such
Sorry folks, a perennial one I'm sure ...
I have read the manual and Googled for a couple of hours but still can't
connect to PostgreSQL 8.3.4 (the PGDG RPMs running on an up to date
CentOS 5.2).
I continually get this message:
psql: could not connect to server: No such file or firectory
Is
On Sun, 2008-10-12 at 00:03 +0930, admin wrote:
psql: could not connect to server: No such file or firectory
Is the server running locally and accepting
connections on Unix domain socket /tmp/.s.PDSQL.0?
Socket file name is wrong -- and the port...
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org,
On Saturday 11 October 2008 7:33:20 am admin wrote:
Sorry folks, a perennial one I'm sure ...
I have read the manual and Googled for a couple of hours but still can't
connect to PostgreSQL 8.3.4 (the PGDG RPMs running on an up to date
CentOS 5.2).
I continually get this message:
psql:
admin [EMAIL PROTECTED] writes:
I continually get this message:
psql: could not connect to server: No such file or firectory
Is the server running locally and accepting
connections on Unix domain socket /tmp/.s.PDSQL.0?
If it's really saying .0, and not .5432, then the problem is on the
I haven't used the command lines previously having relied on PG Admin.
In the instructions -
Starting postmaster
Nothing can happen to a database unless the postmaster process is running. As
the site administrator, there are a number of things you should remember before
starting the
a shell
http://en.wikipedia.org/wiki/Shell_%28computing%29
On Wed, Dec 20, 2006 at 10:59:05AM -0800, Bob Pawley wrote:
I haven't used the command lines previously having relied on PG Admin.
In the instructions -
Starting postmaster
Nothing can happen to a database unless the postmaster
which in PostgreSQL is
Bob
- Original Message -
From: Ray Stell [EMAIL PROTECTED]
To: Bob Pawley [EMAIL PROTECTED]
Cc: Postgresql pgsql-general@postgresql.org
Sent: Wednesday, December 20, 2006 11:07 AM
Subject: Re: [GENERAL] Starting Postgresql
a shell
http://en.wikipedia.org
which in PostgreSQL is
Bob
- Original Message -
From: Bob Pawley [EMAIL PROTECTED]
To: Ray Stell [EMAIL PROTECTED]
Cc: Postgresql pgsql-general@postgresql.org
Sent: Wednesday, December 20, 2006 11:12 AM
Subject: Re: [GENERAL] Starting Postgresql
which in PostgreSQL is
Bob
On 20 Dec 2006 at 11:12, Bob Pawley wrote:
which in PostgreSQL is
It's not in PostgreSQL - it's the shell of your operating system. In
Windows, you get that either by clicking Start - Run and typing
command or cmd (depending on your version of windows), or by
clicking on Start - Programs
Raymond O'Donnell wrote:
On 20 Dec 2006 at 11:12, Bob Pawley wrote:
which in PostgreSQL is
It's not in PostgreSQL - it's the shell of your operating system. In
Windows, you get that either by clicking Start - Run and typing
command or cmd (depending on your version of windows), or by
]
To: Ray Stell [EMAIL PROTECTED]
Cc: Postgresql pgsql-general@postgresql.org
Sent: Wednesday, December 20, 2006 11:12 AM
Subject: Re: [GENERAL] Starting Postgresql
which in PostgreSQL is
Bob
- Original Message -
From: Ray Stell [EMAIL PROTECTED]
To: Bob Pawley [EMAIL
: [GENERAL] Starting Postgresql
Raymond O'Donnell wrote:
On 20 Dec 2006 at 11:12, Bob Pawley wrote:
which in PostgreSQL is
It's not in PostgreSQL - it's the shell of your operating system. In
Windows, you get that either by clicking Start - Run and typing
command or cmd (depending on your
AM
Subject: Re: [GENERAL] Starting Postgresql
Raymond O'Donnell wrote:
On 20 Dec 2006 at 11:12, Bob Pawley wrote:
which in PostgreSQL is
It's not in PostgreSQL - it's the shell of your operating system. In
Windows, you get that either by clicking Start - Run and typing
command
Original Message From Bob Pawley
Here's the url
http://fusion.gat.com/~osborne/dbdoc/postgres/postmaster.htm
Bob,
The above documentation is circa version 7.0.
It might be easier to use the current PostgreSQL official documentation.
See for example:
Bob Pawley wrote:
Here's the url http://fusion.gat.com/~osborne/dbdoc/postgres/postmaster.htm
As the others say, use the official docs. And perhaps drop osborne a
note to let him know his docs are out of date.
--
Richard Huxton
Archonet Ltd
---(end of
Hi I want to start psql as a windows service manually.How to do that?i was able to register the service but able to start it..when i start it ..i got the following message..---Services
---The PostgreSQL service on Local Computer started and then
Rajarajan,please check the postgresql logs witin your data directory pg_logyour data directory defaults to [programs]\Postgresql\8.1\datawhere [programs] is ~Programs and Files in US Windows, and Programme in German Windows.
Propably there is some problem with postgresql.conf or access to your
On Sun, 2005-10-30 at 23:08 -0500, Tom Lane wrote:
Vlad [EMAIL PROTECTED] writes:
I'm looking for some help in regards to letting Posresql use more
memory.
8.0 can't go past 2Gb of shared memory, and there is really no reason
to try because its performance will get worse not better with
On Mon, Oct 31, 2005 at 12:16:59PM +, Simon Riggs wrote:
8.0 can't go past 2Gb of shared memory, and there is really no reason
to try because its performance will get worse not better with more than
about 5 shared buffers.
Unless you turn off the bgwriter, in which case going
On Mon, 2005-10-31 at 14:14 +0100, Martijn van Oosterhout wrote:
On Mon, Oct 31, 2005 at 12:16:59PM +, Simon Riggs wrote:
8.0 can't go past 2Gb of shared memory, and there is really no reason
to try because its performance will get worse not better with more than
about 5 shared
Anyway, the original writer didn't specify an architechure. If it is a
32bit one it is entirly possible that the memory map simply has no
large contiguous space to map the shared memory.
it's 32bit. The actual problem of giving more buffers to postgresql
was solved with the help of the
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2005-10-31 at 14:14 +0100, Martijn van Oosterhout wrote:
On Mon, Oct 31, 2005 at 12:16:59PM +, Simon Riggs wrote:
I'm not sure we have any good tests of that either way, do we? I'm not
certain why we would trust OS cache any more than we could
On Mon, Oct 31, 2005 at 01:34:12PM +, Simon Riggs wrote:
Secondly, you're assuming that PostgreSQLs caching is at least as
efficient as the OS caching, which is more of an assertion than
anything else.
Do you doubt that? Why would shared_buffers be variable otherwise?
Because the
Martijn van Oosterhout kleptog@svana.org writes:
There have been tests that demonstrate that you can raise the buffers
to a certain point which is optimal and after that it just doesn't
help [1]. They peg optimal size at 5-10% of memory.
[1]
On Mon, Oct 31, 2005 at 09:54:39AM -0500, Tom Lane wrote:
Note however that it's reasonable to think that 8.1 may do better than
8.0 did at performing well with large values of shared_buffers,
primarily because we got rid of the StrategyDirtyBufferList overhead:
On Mon, 2005-10-31 at 09:35 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2005-10-31 at 14:14 +0100, Martijn van Oosterhout wrote:
On Mon, Oct 31, 2005 at 12:16:59PM +, Simon Riggs wrote:
I'm not sure we have any good tests of that either way, do we? I'm not
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2005-10-31 at 09:35 -0500, Tom Lane wrote:
The real point is that RAM dedicated to shared buffers can't be used for
anything else [1], whereas letting the kernel manage it gives you some
flexibility (for instance, to deal with transient large
On Mon, 2005-10-31 at 10:58, Simon Riggs wrote:
On Mon, 2005-10-31 at 15:44 +0100, Martijn van Oosterhout wrote:
On Mon, Oct 31, 2005 at 01:34:12PM +, Simon Riggs wrote:
Secondly, you're assuming that PostgreSQLs caching is at least as
efficient as the OS caching, which is more of
On Mon, 2005-10-31 at 14:50 -0600, Scott Marlowe wrote:
As I understand it, when the last backend referencing a collection of
data stops referencing it, that the buffers holding that data are
released, and if, a second later, another backend wants the data, then
it has to go to the Kernel for
On Mon, Oct 31, 2005 at 02:50:31PM -0600, Scott Marlowe wrote:
Your point was about cache efficiency as an argument for not increasing
shared_buffers. Politely, I don't accept that argument. Clearly, there
are some other considerations (for which I agree completely) but those
don't prevent
Scott Marlowe [EMAIL PROTECTED] writes:
I was mainly wondering if that behaviour had changed, if, when the data
are released, they are still held in shared memory until forced out by
newer / more popular data. Which would make the buffer pool a real
cache.
Huh? It's always done that.
On Mon, 2005-10-31 at 15:44, Simon Riggs wrote:
On Mon, 2005-10-31 at 14:50 -0600, Scott Marlowe wrote:
As I understand it, when the last backend referencing a collection of
data stops referencing it, that the buffers holding that data are
released, and if, a second later, another backend
On Mon, 2005-10-31 at 16:12, Tom Lane wrote:
Scott Marlowe [EMAIL PROTECTED] writes:
I was mainly wondering if that behaviour had changed, if, when the data
are released, they are still held in shared memory until forced out by
newer / more popular data. Which would make the buffer pool a
On Mon, 2005-10-31 at 14:48 -0800, Chris Travers wrote:
Simon Riggs wrote:
Your point was about cache efficiency as an argument for not increasing
shared_buffers. Politely, I don't accept that argument. Clearly, there
are some other considerations (for which I agree completely) but those
Hi,
I'm looking for some help in regards to letting Posresql use more
memory. It fails to start with this message:
shmat(id=65536) failed: Cannot allocate shared bufers
Max buffers I can start it with is 115200. Server has 4gig of RAM,
I've adjuted MAXDSIZ to 2.5Gigs. Here is other kernel
Vlad [EMAIL PROTECTED] writes:
I'm looking for some help in regards to letting Posresql use more
memory.
8.0 can't go past 2Gb of shared memory, and there is really no reason
to try because its performance will get worse not better with more than
about 5 shared buffers.
8.1 will relax the
Tom,
I understood your point on memory usage. Out of curiosity - 115200
buffers seems to be little less than 1 gig (I assume 1 buffer = 8k),
so I could not get any closer to 2gigs anyways
Is it practical experience that more than 5 buggers actually hurts
postgresql performance? Any ideas
Hi, i'm working with PostgreSQL for a long time (about three years), but
always on Linux box. But recently, I had to intall PostgreSQL on a WinXP
machine!
The installation works fine, although the starting service did not works in
the finalization of the installation! The installation was
Hi, i'm working with PostgreSQL for a long time (about
three years), but always on Linux box. But recently, I had to
intall PostgreSQL on a WinXP machine!
The installation works fine, although the starting service
did not works in the finalization of the installation! The
hello,
I've been using postgresql for about a year now, and am pretty
comfortable with the basics, bu there has been something bugging me for
a while now:
I set the METHOD in pg_hba.conf to md5 so that a password is required
from all users, from all hosts.
The only problem is that if the
This is not a PostgreSQL problem, it's the script you are using for
startup that has some problem. The pg_hba method is for connection
stablishment. PostgreSQL will start no matter what you put there.
Startup scripts are usually run as root, and postgresql script should su
to the postgresql user
I am using the default startup script that is supplied with the FreeBSD
port (/usr/local/etc/rc.d/010.pgsql.sh) and enabling it in /etc/rc.d
with -o -i flags so listens on TCP/IP
Also, I should mention that the password I mentioned is NOT the password
for the local (Unix) pgsql account, but
mmmhhh, I have never installed postgresql from the ports. I don´t know
what the script is doing, probably it´s checking that Postgresql
directory is initialized.
Anyway, here is my homemade script, you could replace yours with it (check it first, but it´s quite simple).
My script does not tell
# set defaults
postgresql_enable=${postgresql_enable:-NO}
postgresql_flags=${postgresql_flags:--w -s -m fast}
Try it without the -w ... that's probably causing it to try to connect
with psql.
Alternatively, set up a ~/.pgpass file for the postgres user (which
might be a reasonable thing
Title: RE: [GENERAL] Starting postgresql on startup
'linuxconf' on Mandrake 7.1 should be able to set postgres to run at boot time as long as you set Postgresql up from an rpm. If you got to 'Control Panel' - 'Control service activity' - 'postgresql'. Set Startup to automatic and select
46 matches
Mail list logo
