| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Ben Osborne" <bosborne(at)bsdmarketing(dot)co(dot)uk> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: |
| Date: | 2004-10-19 16:30:16 |
| Message-ID: | 16706.1098203416@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Ben Osborne" <bosborne(at)bsdmarketing(dot)co(dot)uk> writes:
> Postgres 7.0.2 Problem
> I am having a rather big problem with an installation of postgres 7.0.2 on
> cobalt, in that the db server is unable to see any of the data stored in the
> (only) database which is running (other than template1).
The symptoms seem reasonably consistent with the theory that you have
suffered transaction ID wraparound. How large is the $PGDATA/pg_log
file? If it's exactly 1Gb then this is almost certainly the answer.
> My Question is, is there ANY means by which I can get at the data.
I believe it is possible to reset the transaction counter to something a
little bit less than 4 billion, which will make everything up to that
point appear to be "in the past" again. I have long since forgotten the
details, but digging in the list archives should turn up some discussion
of how to do that in 7.0. Then do a quick pg_dumpall, initdb and
reload.
You should seriously consider updating to a more modern PG version
while you are at it ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-10-19 17:06:06 | Re: Using ALTER TABLESPACE in pg_dump |
| Previous Message | Steve Atkins | 2004-10-19 16:24:42 | Re: embedded postgresql |