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
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 t
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:
>
> p
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
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 broadcast)-
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:
http://www.postgresql.org/docs/8.2/sta
mber 2006 11:57, Bob Pawley wrote:
> Here's the url http://fusion.gat.com/~osborne/dbdoc/postgres/postmaster.htm
>
> Bob
>
>
> - Original Message -
> From: "Richard Huxton"
> To: "Raymond O'Donnell" <[EMAIL PROTECTED]>
> Cc: "
Here's the url http://fusion.gat.com/~osborne/dbdoc/postgres/postmaster.htm
Bob
- Original Message -
From: "Richard Huxton"
To: "Raymond O'Donnell" <[EMAIL PROTECTED]>
Cc: "Postgresql"
Sent: Wednesday, December 20, 2006 11:43 AM
Subject
uot;Bob Pawley" <[EMAIL PROTECTED]>
> To: "Ray Stell" <[EMAIL PROTECTED]>
> Cc: "Postgresql"
> Sent: Wednesday, December 20, 2006 11:12 AM
> Subject: Re: [GENERAL] Starting Postgresql
>
>
> > which in PostgreSQL is
> >
> >
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
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 -> Pr
which in PostgreSQL is
Bob
- Original Message -
From: "Bob Pawley" <[EMAIL PROTECTED]>
To: "Ray Stell" <[EMAIL PROTECTED]>
Cc: "Postgresql"
Sent: Wednesday, December 20, 2006 11:12 AM
Subject: Re: [GENERAL] Starting Postgresql
which
which in PostgreSQL is
Bob
- Original Message -
From: "Ray Stell" <[EMAIL PROTECTED]>
To: "Bob Pawley" <[EMAIL PROTECTED]>
Cc: "Postgresql"
Sent: Wednesday, December 20, 2006 11:07 AM
Subject: Re: [GENERAL] Starting Postgresql
a
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 postmas
Rajarajan,please check the postgresql logs witin 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 datafiles; the log
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 thos
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
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
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, 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
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
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
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 lar
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'
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 an assertion than
> > > anything else.
> >
> >
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:
> http://archives.postgresql.o
Martijn van Oosterhout 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] http://archives.postgresql.org/pgsql-performance/2004-10/msg00110.
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
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
> 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 follo
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
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 goi
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 bett
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
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 t
> 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
> instal
>> # 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
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 po
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 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 t
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' -> 'postgres
41 matches
Mail list logo
