Обсуждение: Re: [GENERAL] Postgres DB is failed due to pg_Xlog is continues full.
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
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 Thursday, September 14, 2017, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
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
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 Thursday, September 14, 2017, Michael Paquier <michael.paquier@gmail.com> 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
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