| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Moshe Jacobson <moshe(at)neadwerx(dot)com> |
| Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Suddenly all tables were gone |
| Date: | 2014-01-03 19:42:36 |
| Message-ID: | 7112.1388778156@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Moshe Jacobson <moshe(at)neadwerx(dot)com> writes:
> Yesterday I found that one of the databases in my database cluster suddenly
> lost all its tables. A \dt in psql showed nothing. I'm not sure how or when
> it happened, but it was either due to an upgrade of postgres from 9.1 to
> 9.3 or else something going wrong with pg_dump.
This sounds like a transaction ID wraparound issue, ie, the pg_class rows
are still there but you can't see them because they're "in the future".
VACUUM FREEZE would probably fix it, but the interesting question is why
didn't the built-in wraparound defenses prevent this from happening.
Could we see the output from pg_controldata?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Clemens Eisserer | 2014-01-03 19:59:54 | Creating an index alters the results returned |
| Previous Message | Kevin Grittner | 2014-01-03 19:24:51 | Re: pg_largeobject related issue with 9.2 |