From: | Chris Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Solving OID wrap-around in 7.4 DB? |
Date: | 2005-10-17 17:04:59 |
Message-ID: | 60fyr0gjlw.fsf@dba2.int.libertyrms.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
jeff(at)endpoint(dot)com (Jeff Boes) writes:
> On behalf of a previous employer who, due to major downsizing, is left
> without an answer to this:
>
> What's the best way to treat impending OID wrap-around in a 7.4.8
> database? This DB has been online for about 18 months, and is expected
> to hit the dreaded wrap-around in about a month. At an application
> level, there's some small chance that OID wrap will cause failures:
> there's code that writes rows, and (for tables without primary keys)
> relies on DBD::Pg's pg_oid_status method to identify the last INSERT.
> (The vast majority of the code does not rely on this, but there's a tiny
> fraction that does, and rewriting the code to remove this is not an
> option due to the aforementioned downsizing.)
>
> My immediate take on this is that the only sure way to avoid the
> problem would be to dump and reload the database. Due to the size of
> the database, this is likely to take most of a day. Any other
> options?
Another method would be to use replication to load the data into a
fresh DB instance.
You could, in principle, use Slony-I to do this; that is an intended
sort of "use case."
--
output = ("cbbrowne" "@" "acm.org")
http://www3.sympatico.ca/cbbrowne/slony.html
"What if you slept? And what if, in your sleep, you dreamed?
And what if, in your dream, you went to heaven and there
plucked a strange and beautiful flower? And what if, when
you awoke, you had the flower in your hand? Ah, what then?"
--Coleridge
From | Date | Subject | |
---|---|---|---|
Next Message | Roth, Gabrielle | 2005-10-17 19:45:41 | solaris install - 8.0.3 config fails on openssl, 7.4 config works |
Previous Message | Jim C. Nasby | 2005-10-17 14:28:52 | Re: help with pg_dump timings |