From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | Anibal David Acosta <aa(at)devshock(dot)com> |
Cc: | 'Raghavendra' <raghavendra(dot)rao(at)enterprisedb(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Help, server doesn't start |
Date: | 2012-06-25 04:53:32 |
Message-ID: | 4FE7EECC.20301@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 06/25/2012 12:40 PM, Anibal David Acosta wrote:
>
> Yes, we must upgrade.
>
> The value of the shared_preload_libraries is
>
> shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll' #
> (change requires restart)
>
Change that to:
shared_preload_libraries = ''
(two single quotes, not a double quote)
It's unlikely that the PL/PgSQL debugger plugin is the issue, but since
it's repeated in your logs, it's worth a go.
>
> When I login into the server the disk used by Postgres installation
> was without space (0Bytes available).
>
>
OK, so you probably do just have xlogs that're cut short. So long as
nobody tried to "fix" the problem by deleting things out of the
PostgreSQL data directory I expect you'll be OK.
AFAIK Pg is supposed to recover gracefully from out-of-disk situations,
but this _is_ quite an old version.
I wonder if there are any out-of-disk tests in the Pg unit tests? It'd
be somewhat tricky to automate testing for, but really good to do if
it's practical. Something for my bored-weekend TODO I guess, even if
it's just a standalone test set.
> Right now I am making a file-level copy of the entire postgres folder
> in order to run some corruption recover method
Great.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Schwarzer | 2012-06-25 05:44:27 | Re: pg_dump not dumping all tables |
Previous Message | Raghavendra | 2012-06-25 04:50:10 | Re: Help, server doesn't start |