Re: Postgres DB is failed due to pg_Xlog is continues full.

On 14/09/17 15:29, Yogesh Sharma wrote:

Dear All,

Thanks in advance.

We are using Postgres 8.1.18 version.
In Postgres log, we found below logs.
–---------------------
CONTEXT:writing block 0 of relation 1664/0/1260
ERROR: could not write block 0 of relation 1664/0/1260: Bad address

------------------------
Due to this pglog_Xlog directory has been continuously increased and
directory has been full and Postgres is stopped.
Please let me know how to recover this issue.

Regards.
Yogesh

When you have recovered from that - I strong suggest that you consider
upgrading to a supported version of Postgres like 9.6.5, as Postgres 8
is no longer supported and later versions have many bug fixes and
enhancements!  Note that Postgres will be released in a few weeks.

Cheers,
Gavin

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On 9/13/2017 8:29 PM, Yogesh Sharma wrote:

We are using Postgres 8.1.18 version.
In Postgres log, we found below logs.
–---------------------
CONTEXT:writing block 0 of relation 1664/0/1260
ERROR: could not write block 0 of relation 1664/0/1260: Bad address

------------------------
Due to this pglog_Xlog directory has been continuously increased and
directory has been full and Postgres is stopped.
Please let me know how to recover this issue.

PostgreSQL 8.1 has been unsupported for quite a long time. 8.1.18 was
released in 2009, 8.1.23 was the last update of 8.1 in late 2010.

the oldest 'supported' postgres is 9.2, and thats at EOL.

prior to that error, something else catastrophic must have happened to
the system, that error is more of a side effect. recovering a database
server that far gone which is running such an obsolete version will
likely be an expensive proposition. before doing anything, you should
make a complete backup of the $PGDATA directory (and other tablespace
directories, if you use any).

--
john r pierce, recycling bits in santa cruz

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Dear all,

As current situation, i can not upgrade on higher version.

Is there any recovery command available?

Regards,
Yogesh

On Thursday, September 14, 2017, Gavin Flower <GavinFlower@archidevsys.co.nz>
wrote:

On Thu, Sep 14, 2017 at 12:44 PM, John R Pierce <pierce@hogranch.com> wrote:

prior to that error, something else catastrophic must have happened to the
system, that error is more of a side effect. recovering a database server
that far gone which is running such an obsolete version will likely be an
expensive proposition. before doing anything, you should make a complete
backup of the $PGDATA directory (and other tablespace directories, if you
use any).

Definitely take a backup of PGDATA before doing anything! What you
could do is copying its contents to a large disk, and then allow it to
recover from the crash. You are going to need more space at the end.
And yes, upgrade as well. Lagging 7 major releases behind cannot be an
excuse.
--
Michael

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

What you could do is copying its contents to a large disk, and then allow

it to recover from the crash.
I will copy the PGDATA into large disk. After that it is require to
execute some specific command or automatically recovery will start?
If any command is require to execute please let me know.
Regards,
Yogesh

On Thursday, September 14, 2017, Michael Paquier <michael.paquier@gmail.com>
wrote:

On 9/13/2017 9:11 PM, Yogesh Sharma wrote:

What you could do is copying its contents to a large disk, and then

allow it to recover from the crash.
 I will copy the PGDATA into large disk. After that it is require to
execute some specific command or automatically recovery will start?
If any command is require to execute please let me know.

you're going to need an experienced postgres admin who understands low
level disk recovery.    there's a variety of postgres businesses who
offer such services for hire.

--
john r pierce, recycling bits in santa cruz

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On 14/09/17 16:11, Yogesh Sharma wrote:

What you could do is copying its contents to a large disk, and then

allow it to recover from the crash.
 I will copy the PGDATA into large disk. After that it is require to
execute some specific command or automatically recovery will start?
If any command is require to execute please let me know.
Regards,
Yogesh

If appropriate, can insert comments directly after the associated text.

On Thursday, September 14, 2017, Michael Paquier
<michael.paquier@gmail.com <mailto:michael.paquier@gmail.com>> wrote:

On Thu, Sep 14, 2017 at 12:44 PM, John R Pierce
<pierce@hogranch.com <javascript:;>> wrote:

[...]

Hi Yogesh,

Please post followups to emails at the end, called 'bottom posting' like
this.  It is the convention in the Postgres mailing lists, and makes it
easier to get the context.

If a lot of the the previous text is no longer relevant it can be
omitted and replaced by '[...]'.

Thanks,
Gavin

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general