On Oct 13, 2005, at 9:35 PM, Tom Lane wrote:
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
When I restart, everything seems to come up fine with the exception
that postmaster starts in a state such that it doesn't seem to be
accepting connections (either over UNIX or TCP/IP). As best I ca
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> When I restart, everything seems to come up fine with the exception
> that postmaster starts in a state such that it doesn't seem to be
> accepting connections (either over UNIX or TCP/IP). As best I can
> tell, it is using the init script t
On Thu, 13 Oct 2005, Thomas F. O'Connell wrote:
The very odd thing is that if I use this same init script manually once the
box is up to stop/start postgres, everything comes up roses.
You could post your init script for us to look at, but my first question is
this: Is postgresql actually run
I'm experiencing an unusual situation on a recently reprovisioned
server.
It's a Debian server (testing/unstable) running a 2.6.13.3 kernel.
postgres 8.0.4 was built from source. I'm using a slightly modified
version of the tarball sample init script that includes a function to
start pg_a
> Noticed in the documentation that the values for this
> parameter can be found in wxs/pginst.wxs, but have not been
> able to find this on either an installed platform or on the
> source disk.
You'll find it in the cvs source to the insaller on the pgfoundry page
at
http://cvs.pgfoundry.org/c
Noticed in the documentation that the values for this parameter can be found
in
wxs/pginst.wxs, but have not been able to find this on either an installed
platform
or on the source disk.
I have been Googling for the values that can be set and what they are useful
for,
but none found. Hate to use '
"Nigel Bishop" <[EMAIL PROTECTED]> writes:
> Hmm... a possible bug eh! I'll make sure that the log destination
> doesn't fill again
> This is what I have in the postgresql.conf file:
> log_destination = 'stderr'
> redirect_stderr = true
I tried to reproduce the problem, without any success
Hi
Hmm... a possible bug eh! I'll make sure that the log destination
doesn't fill again
This is what I have in the postgresql.conf file:
log_destination = 'stderr'
redirect_stderr = true
log_directory = '/opt/postgres/admin/log'
log_filename = 'PG-%Y-%m-%d_%H%M%S.log'
Thanks,
Nigel
-
On Thu, 2005-10-13 at 11:23, Bruce Momjian wrote:
> Scott Marlowe wrote:
> > On Thu, 2005-10-13 at 10:56, Bruce Momjian wrote:
> > > codeWarrior wrote:
> > > > Lookas as if you've managed to turn off your computer mid-transaction
> > > > thereby corrupting the postgreSQL commit logs (pg_clog)...
>
If you can't / won't / don't use syslog and want your logs rotated
anyway, look at apache's log rotator. It works a charm, and rotates
every night at midnight the way I use it. Quite simple to set up and
very reliable.
On Thu, 2005-10-13 at 10:48, codeWarrior wrote:
> Are you possibly running lo
Bruce Momjian writes:
>> You should never just turn off a database server... always shut it down
>> normally... Turning it off was a major mistake.
> PostgreSQL should never get corrupted by turning off the server. It
> isn't ideal to do that, but it should not get corrupted.
We can only make
Scott Marlowe wrote:
> On Thu, 2005-10-13 at 10:56, Bruce Momjian wrote:
> > codeWarrior wrote:
> > > Lookas as if you've managed to turn off your computer mid-transaction
> > > thereby corrupting the postgreSQL commit logs (pg_clog)...
> > >
> > > You should never just turn off a database server
On Thu, 2005-10-13 at 10:56, Bruce Momjian wrote:
> codeWarrior wrote:
> > Lookas as if you've managed to turn off your computer mid-transaction
> > thereby corrupting the postgreSQL commit logs (pg_clog)...
> >
> > You should never just turn off a database server... always shut it down
> > norm
Are you possibly running logrotate on the postgreSQL server logs ? Logrotate
is usually set to signal (SIGHUP) the log owner (in this case -- postgreSQL)
after rotating the log file...
You normally can't just delete the logfiles and expect postgreSQL to
continue wherever you left it... you norm
Nirav Parikh wrote:
> Hi,
>
> I got this error message when I tried to do pg_dump on the database.
>
> pg_dump: ERROR: invalid memory alloc request size 4294967293
> pg_dump: SQL command to dump the contents of table "wordlist" failed:
> PQendcopy() failed.
> pg_dump: Error message from server:
Nigel Bishop <[EMAIL PROTECTED]> writes:
> Last night at 3am our Postgresql DB cluster hung. At the time data
> was being loaded. The parameter log_statement_stats in the
> postgresql.conf file was set to true. This was churning out data into
> the logfile which was switching every 10Mb. Eventu
codeWarrior wrote:
> Lookas as if you've managed to turn off your computer mid-transaction
> thereby corrupting the postgreSQL commit logs (pg_clog)...
>
> You should never just turn off a database server... always shut it down
> normally... Turning it off was a major mistake. I dont know if you
I've been through a similar situation before (partition was full, and
subsequently, PG wasn't able to access a pg_clog/.
Tom Lane had referred me to another archive about zeroing out that
particular file, which had worked for me and the database was up.
And yes, don't shutdown the machine like th
Lookas as if you've managed to turn off your computer mid-transaction
thereby corrupting the postgreSQL commit logs (pg_clog)...
You should never just turn off a database server... always shut it down
normally... Turning it off was a major mistake. I dont know if you can
recover or not as the s
Hi,
I'm hoping that someone will be able to answer this query:
Last night at 3am our Postgresql DB cluster hung. At the time data
was being loaded. The parameter log_statement_stats in the
postgresql.conf file was set to true. This was churning out data into
the logfile which was switching eve
20 matches
Mail list logo
