Обсуждение: [HACKERS] ERROR: MultiXactId 3268957 has not been created yet -- apparentwraparound after missused pg_resetxlogs

Поиск
Список
Период
Сортировка

Hi,

 

I’m facing a problem with a PostgreSQL 9.6.2 reporting this error when selecting a table

ERROR:  MultiXactId 3268957 has not been created yet -- apparent wraparound

 

The root cause is not a Postgres bug but a buggy person that used pg_resetxlogs obviously without reading or understanding the documentation.

 

I’m trying to extract data from the db to create a new one ;-)

But pg_dump logically end with the same error.

 

I’ve seen the row with t_max  = 3268957 page_inspect, I might use it to extract row from the page, but this will not be quite easy.

 

Is there a way to change the t_max to a value that won’t fire the error, with this row.

 

Could pg_filedump be used in this problem configuration.

 

As usual, xlogs where  deleted even stored in a directory named pg_wal L ( I made the change before 10 ) and xlogs reseted by the same person that commented the backup months ago.

 

Hopefully, this is not a production database :-D but the user want to start qualification of the new application version today .. no luck for him.

 

Any advice of how to extract data is welcome.

 

At least, there is something to learn, renaming pg_xlog to pg_wal won’t stop everybody :-/

 

Regards.

  Alain Radix



On Mon, Oct 16, 2017 at 5:41 PM, alain radix <alain.radix@gmail.com> wrote:
> I’m facing a problem with a PostgreSQL 9.6.2 reporting this error when
> selecting a table
>
> ERROR:  MultiXactId 3268957 has not been created yet -- apparent wraparound
>
> The root cause is not a Postgres bug but a buggy person that used
> pg_resetxlogs obviously without reading or understanding the documentation.

Hmm, I hope you patched that person...

> I’m trying to extract data from the db to create a new one ;-)
>
> But pg_dump logically end with the same error.
>
> I’ve seen the row with t_max  = 3268957 page_inspect, I might use it to
> extract row from the page, but this will not be quite easy.

Not sure if this would work, but maybe try BEGIN ... UPDATE the row,
perhaps via TID qual ... ROLLBACK?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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