Greg,
Does pg_ctl stop -m immediate stop the postmaster for you?
Jeff Frost, Owner <[EMAIL PROTECTED]>
Frost Consulting, LLC http://www.frostconsultingllc.com/
Phone: 650-780-7908 FAX: 650-649-1954
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] O
You wrote:
>
> Greg,
>
> Does pg_ctl stop -m immediate stop the postmaster for you?
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:
2006-01-01 23:20:19 WARNING: termina
Thanks for answer.However i have already searched for a way to make count
faster and didn't find anything.
Any pointers will be appreciated.
Thanks.
Evgeny.
On Wed, 28 Dec 2005, Bruno Wolff III wrote:
> On Tue, Dec 27, 2005 at 11:48:55 +0200,
> Tsirkin Evgeny <[EMAIL PROTECTED]> wrote:
> >
> > Hi
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:
---(
"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
I received the following error message when trying to copy a table from
one database to another on the same cluster:
pg_dump: The command was: FETCH 100 FROM _pg_dump_cursor
pg_restore: [custom archiver] could not read data block -- expected 1,
got 0
pg_restore: *** aborted because of error
The t
warren little <[EMAIL PROTECTED]> writes:
> I received the following error message when trying to copy a table from
> one database to another on the same cluster:
> pg_dump: The command was: FETCH 100 FROM _pg_dump_cursor
> pg_restore: [custom archiver] could not read data block -- expected 1,
> g
Tom,
The extent of the messages I received from the command
pg_dump -Fc --table=casedocument -d tigrissave | pg_restore --verbose -d
tigris is listed below:
pg_dump: SQL command failed
pg_dump: Error message from server: server closed the connection
unexpectedly
This probably means the se
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
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
warren little <[EMAIL PROTECTED]> writes:
> pg_dump: SQL command failed
> pg_dump: Error message from server: server closed the connection
> unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> pg_dump: The command was: FET
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 -- I have some documentation though that says it
is 7.4.2 so I th
"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 --
The dump/restore failed even with the zero_damaged_pages=true.
The the logfile (postgresql-2006-01-02_130023.log)
did not have much in the way of useful info. I've attached the section
of the logfile around the time of the crash. I cannot find any sign of
a core file. Where might the core dump ha
Sorry,
forget the attachment.
On Mon, 2006-01-02 at 15:24 -0700, warren little wrote:
> The dump/restore failed even with the zero_damaged_pages=true.
> The the logfile (postgresql-2006-01-02_130023.log)
> did not have much in the way of useful info. I've attached the section
> of the logfile arou
Ah well, figures. If only ops had listened to me, we'd be on 8.1 right now.
Thanks anyway, as always, for the sage advice.
G
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Mon 1/2/2006 2:11 PM
To: Gregory S. Williamson
Cc: Jeff Frost; pgsql-admin@postgresq
warren little <[EMAIL PROTECTED]> writes:
> The dump/restore failed even with the zero_damaged_pages=true.
> The the logfile (postgresql-2006-01-02_130023.log)
> did not have much in the way of useful info. I've attached the section
> of the logfile around the time of the crash. I cannot find any
17 matches
Mail list logo
