Re: Wrap around id failure and after effects

From: Richard Huxton <dev(at)archonet(dot)com>
To: "Arun P(dot)L" <arunpl(at)hotmail(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Wrap around id failure and after effects
Date: 2013-11-26 09:44:10
Message-ID: 52946D6A.5080700@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 26/11/13 07:15, Arun P.L wrote:
> Hi all,
>
> We had a wraparound failure in the db and most of the tables and data
> were missing. So we have done a full vacuum in db and after that the
> tables reappeared but now the problem is, all the tables have duplicate
> when listing tables with /dt. And also after the vacuum we recievied the
> following warning.
>
> *INFO: free space map: 48 relations, 29977 pages stored; 134880 total
> pages needed*
> *DETAIL: Allocated FSM size: 1000 relations + 20000 pages = 215 kB
> shared memory.*
> *WARNING: some databases have not been vacuumed in over 2 billion
> transactions*
> *DETAIL: You may have already suffered transaction-wraparound data loss.*
> *
> *
>
> Is this an error happened between the vacuum? If so what can be done
> next to prevent data loss? The vacuum was not done as superuser, we are
> doing a second time vacuum as superuser now. And what are the further
> steps to be followed now like reindexing,etc?

1. Did you take a full file-level backup of things before vacuuming?

2. What version?

3. How far back in the logs do the warnings go (you should have been
receiving warnings for a long time)?

4. How/why had you disabled/altered the autovacuum daemon?

This shouldn't really be possible without disabling autovaccuum or
configuring it strangely.

http://www.postgresql.org/docs/current/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND

--
Richard Huxton
Archonet Ltd

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Albe Laurenz 2013-11-26 11:19:33 Re: Autodocumenting plpgsql function
Previous Message Rémi Cura 2013-11-26 08:40:40 Autodocumenting plpgsql function