Re: [ADMIN] BAcking up a Postgres Database

2001-01-10 Thread Ragnar Kjørstad
On Wed, Jan 10, 2001 at 05:57:21AM -0600, D Johnson wrote: > Will the postgres community ever consider creating a decent backup > capability. Currently the way to create backups is through a Cron job. > For Postgres to ever be considered a true production systen then some > sort of transactional t

Re: [ADMIN] BAcking up a Postgres Database

2001-01-10 Thread Dr. Hans-Christian Waldmann
> > Will the postgres community ever consider creating a decent backup > capability. Currently the way to create backups is through a Cron job. > For Postgres to ever be considered a true production systen then some > sort of transactional tracing has to be done. Otherwise you risk the > potentia

[ADMIN] BAcking up a Postgres Database

2001-01-10 Thread D Johnson
Will the postgres community ever consider creating a decent backup capability. Currently the way to create backups is through a Cron job. For Postgres to ever be considered a true production systen then some sort of transactional tracing has to be done. Otherwise you risk the potential of losing q

[ADMIN] Re: Postmaster crashes with "Serverloop: select failed" message

2001-01-10 Thread Paul Breen
Thanks Tom, We applied a modified version of the patch by hand. Looking through the code it does seem that the patch should fix the problem we were having. However because we've never been able to forcibly reproduce the problem ourselves for testing it's just a case of keeping an eye on things

[ADMIN] Postgres 7.1 features

2001-01-10 Thread Schmidt, Peter
Title: Postgres 7.1 features The 7.1 Release notes include the statement re WAL below. "Write-ahead Log (WAL) To maintain database consistency in case of an operating system crash, previous releases of PostgreSQL have forced all data modifications to disk before each transaction commit. Wi

Re: [ADMIN] multiple postmasters

2001-01-10 Thread Peter Eisentraut
Ross J. Reedstrom writes: > Another aspect of this problem is that, on most platforms, the children > of postmaster that are forked for each connection rename themselves > to 'postgres'. The code for this was changed, recently, due to some > potential speed, security, or portability problems (I'm

Re: [ADMIN] multiple postmasters

2001-01-10 Thread Ross J. Reedstrom
On Wed, Jan 10, 2001 at 01:34:34PM -0600, David Mehringer wrote: > On Wed, 10 Jan 2001, Peter Eisentraut wrote: > > > > > We're running postgresql 7.0.2 on solaris 5.7. The admin docs say that only > > > one postmaster process should be running. > > > > The docs are wrong in that case. Can you

Re: [ADMIN] multiple postmasters

2001-01-10 Thread David Mehringer
On Wed, 10 Jan 2001, Peter Eisentraut wrote: > > > We're running postgresql 7.0.2 on solaris 5.7. The admin docs say that only > > one postmaster process should be running. > > The docs are wrong in that case. Can you name chapter and section so we > can fix it? > Hi, Thanks for the quick re

Re: [ADMIN] multiple postmasters

2001-01-10 Thread Peter Eisentraut
David Mehringer writes: > We're running postgresql 7.0.2 on solaris 5.7. The admin docs say that only > one postmaster process should be running. The docs are wrong in that case. Can you name chapter and section so we can fix it? > However, our "master" postmaster > process (PID=560 below) ap

[ADMIN] multiple postmasters

2001-01-10 Thread David Mehringer
Hi, We're running postgresql 7.0.2 on solaris 5.7. The admin docs say that only one postmaster process should be running. However, our "master" postmaster process (PID=560 below) appears to have spawned off a couple of other postmaster processes: UID PID PPID CSTIME TTY TIME C

Re: [ADMIN] Granting Permissions to User To Access Database

2001-01-10 Thread Peter Eisentraut
Radoslaw Stachowiak writes: > > The problem with this approach is that if you do "revoke all on database > > from all" you have hosed your system. Text files allow recovery in these > > situations. > > thats completly wrong :) look at the whole UNIX dir permissions topic. > Using postgres super

Re: [ADMIN] Granting Permissions to User To Access Database

2001-01-10 Thread Radoslaw Stachowiak
*** Peter Eisentraut <[EMAIL PROTECTED]> [Tuesday, 09.January.2001, 18:50 +0100]: > > This is one of the features of PgSQL that I do not > > like. It is much nicer to type: > > "grant all on database.table to ." > > And I asked the developers to do that but they did not > > take it very seriou

[ADMIN] v7.1 & WAL

2001-01-10 Thread Peter Schmidt
The 7.1 Release notes include the statement re WAL below. "Write-ahead Log (WAL) To maintain database consistency in case of an operating system crash, previous releases of PostgreSQL have forced all data modifications to disk before each transaction commit. With WAL, only one log file must be fl

Re: [ADMIN] Granting Permissions to User To Access Database

2001-01-10 Thread R D
--- Peter Eisentraut <[EMAIL PROTECTED]> wrote: > R D writes: > > > This is one of the features of PgSQL that I do not > > like. It is much nicer to type: > > "grant all on database.table to ." > > And I asked the developers to do that but they did > not > > take it very seriously. > > The