Re: [ADMIN] Recovery from Transaction wraparound failure

Поиск
Список
Период
Сортировка
От Ganesh Kannan
Тема Re: [ADMIN] Recovery from Transaction wraparound failure
Дата
Msg-id DM5PR07MB27477C8095FCD878B763C3D786420@DM5PR07MB2747.namprd07.prod.outlook.com
обсуждение исходный текст
Ответ на Re: [ADMIN] Recovery from Transaction wraparound failure  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-admin

Hi Tom,

Thank you much for the timely help. I continued executing vacuum for the select tables in single user mode (ignoring warning) and the database is back to accepting writes. 


Thanks

Ganesh





From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Wednesday, February 8, 2017 11:13:47 AM
To: Ganesh Kannan
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Recovery from Transaction wraparound failure
 
Ganesh Kannan <ganesh.kannan@weatheranalytics.com> writes:
> 1) After reading the documentation, I thought I could try to vacuum
> those 20 tables that were never vacuumed individually ( with relfrozenid
> more than 2 billion) in single-user mode, but it is not working (error
> copied below).

That is not an error, it's just a warning:

> backend>  vacuum freeze schema.wd_p51_y2015;
> 2017-02-07 23:25:15 EST [54045]: [8-1] user=,db=,app=,client= WARNING:  database "db1" must be vacuumed within 999999 transactions
> 2017-02-07 23:25:15 EST [54045]: [9-1] user=,db=,app=,client= HINT:  To avoid a database shutdown, execute a database-wide VACUUM in that database.

It's telling you that you haven't finished fixing the problem, not that
this command didn't do anything.

> Is there a way to do vacuum of individual tables in
> single-user mode?

You're doing it.  I don't think you really need the "freeze" modifier
though, and that may be forcing more I/O than is needed to get out of
trouble.

                        regards, tom lane

В списке pgsql-admin по дате отправления:

Предыдущее
От: "Lazaro Garcia"
Дата:
Сообщение: [ADMIN] Why pgpool TPS is lowest versus postgresql direct connections?
Следующее
От: Kevin Duffy
Дата:
Сообщение: [ADMIN] Change ownership of a database