On Sat, Jan 07, 2006 at 05:56:33AM -0800, Gregory S. Williamson wrote:
> But like I've said, I am reasonably certain that 8.1/postGIS 1.0 will
> be better and I don't want to waste anyone's time chasing after bugs
> that may have already been swatted.
The PostGIS developers have fixed a lot of cra
Back in the way-back Tom Lane wrote:
>
> Actually, as a developer I would've first wanted to look into the core
> files and try to see why they showed up in the first place. A gdb stack
> trace would often tell something useful (... if not to you, then to
> someone on the -hackers list ...). Cle
Tom Lane pravi:
Tomaz Borstnar <[EMAIL PROTECTED]> writes:
Jeff Frost pravi:
Seems like you're going to have to kill -9.
Yeah, this is bad :( Seems like kill -9 is needed when disk is full. Tested on
*BSD jails.
With what PG version?
8.0.x for sure.
And what behavior did you see exact
Tom Lane conjured forth the following characters:
>
> > Might want to turn off dumping of core files; I believe man ulimit is
> > the place to look.
>
> Actually, as a developer I would've first wanted to look into the core
> files and try to see why they showed up in the first place. A gdb sta
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Tue, Jan 03, 2006 at 05:17:45PM -0800, Gregory S. Williamson wrote:
>> I went sleuthing and found some core files in the ./base/13860299 directory.
>> Deleteing those freed up some gigabytes of space (each core was 1-2 gigs).
> Might want to turn of
On Tue, Jan 03, 2006 at 05:17:45PM -0800, Gregory S. Williamson wrote:
> FWIW,
>
> I can at least report the resolution of the original problem.
>
> I went sleuthing and found some core files in the ./base/13860299 directory.
> Deleteing those freed up some gigabytes of space (each core was 1-2
On Tue, 3 Jan 2006, Jim C. Nasby wrote:
Another alternative: most unix filesistems actually set it up so that
there is still some free space left even if it's reporting 100%. On
FreeBSD, you can change the amount of reserved space with tunefs -m, but
you should read the caveats in man tunefs.
rg
Subject: Re: [ADMIN] full data disk -- any chance of recovery
Tomaz Borstnar <[EMAIL PROTECTED]> writes:
> Jeff Frost pravi:
>> Seems like you're going to have to kill -9.
> Yeah, this is bad :( Seems like kill -9 is needed when disk is full. Tested
> on *BSD
On Mon, Jan 02, 2006 at 12:45:29PM -0500, Tom Lane wrote:
> "Gregory S. Williamson" <[EMAIL PROTECTED]> writes:
> > 2006-01-02 00:30:01 LOG: could not close temporary statistics file
> > "/data/postgres/gex_runtime/global/pgstat.tmp.1453": No space left on device
> > 2006-01-02 00:33:54 ERROR: c
Tomaz Borstnar <[EMAIL PROTECTED]> writes:
> Jeff Frost pravi:
>> Seems like you're going to have to kill -9.
> Yeah, this is bad :( Seems like kill -9 is needed when disk is full. Tested
> on *BSD jails.
With what PG version? And what behavior did you see exactly?
rega
Jeff Frost pravi:
Seems like you're going to have to kill -9.
Yeah, this is bad :( Seems like kill -9 is needed when disk is full. Tested on
*BSD jails.
Tomaž
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
admin@postgresql.org
Subject: Re: [ADMIN] full data disk -- any chance of recovery
"Gregory S. Williamson" <[EMAIL PROTECTED]> writes:
> I'll check into the temp files and the like in a bit -- the output from
> version() says:
> PostgreSQL 7.4 on i686-pc-linux-g
"Gregory S. Williamson" <[EMAIL PROTECTED]> writes:
> I'll check into the temp files and the like in a bit -- the output from
> version() says:
> PostgreSQL 7.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.2
> (Mandrake Linux 9.1 3.2.2-3mdk)
> (1 row)
> so I am not sure if this 7.4.2 --
so I think this beast may be of that flavor.
'
Thanks,
Greg
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Mon 1/2/2006 9:45 AM
To: Gregory S. Williamson
Cc: Jeff Frost; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] full data disk -- any chance o
Ben Kim wrote:
Just curious, I guess the problem is not simply the disk full now, but
supposing the disk full is the only problem, what would happen if we move
some old files temporarily from pg_xlog/* to somewhere else and free up
some disk space? (On mine, I guess I can get about 75 MB, leavin
Just curious, I guess the problem is not simply the disk full now, but
supposing the disk full is the only problem, what would happen if we move
some old files temporarily from pg_xlog/* to somewhere else and free up
some disk space? (On mine, I guess I can get about 75 MB, leaving the most
recent
"Gregory S. Williamson" <[EMAIL PROTECTED]> writes:
> 2006-01-02 00:30:01 LOG: could not close temporary statistics file
> "/data/postgres/gex_runtime/global/pgstat.tmp.1453": No space left on device
> 2006-01-02 00:33:54 ERROR: could not access status of transaction 0
> DETAIL: could not write
Seems like you're going to have to kill -9.
On Mon, 2 Jan 2006, Gregory S. Williamson wrote:
I tried
su - postgres -c '/apps/pgsql-7.4/bin/pg_ctl stop -D /data/postgres/gex_runtime
-m immediate'
on one of the two hozed servers and that's (I think) what got this:
---(
g, LLC http://www.frostconsultingllc.com/
Phone: 650-780-7908 FAX: 650-649-1954
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gregory S. Williamson
Sent: Sunday, January 01, 2006 11:58 PM
To: Jeff Frost; pgsql-admin@postgresql.org
Subject: Re: [ADMIN]
TECTED] On Behalf Of Gregory S. Williamson
Sent: Sunday, January 01, 2006 11:58 PM
To: Jeff Frost; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] full data disk -- any chance of recovery
Jeff --
Thanks for the suggestion -- I think this fills the bill except that the
postmaster won't quit bec
org
Cc:
Subject: RE: [ADMIN] full data disk -- any chance of recovery
Greg, I'm not sure what you're looking for in the way of suggestions. Do
you just want to be able to start this postgres server up and remove some
data? Easiest way I see to accomplish that given the infor
Greg, I'm not sure what you're looking for in the way of suggestions. Do
you just want to be able to start this postgres server up and remove some
data? Easiest way I see to accomplish that given the information you
provided is to move pg_xlog to the sda disk and symlink it to the data dir.
In
22 matches
Mail list logo
