From: | Daniel Kalchev <daniel(at)digsys(dot)bg> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: OID wraparound (was Re: pg_depend) |
Date: | 2001-07-19 12:30:24 |
Message-ID: | 200107191230.PAA13534@dcave.digsys.bg |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>Bruce Momjian said:
[...]
> > No, we won't, because OID wrap is an issue already for any long-uptime
> > installation. (64-bit XIDs are not a real practical answer either,
> > btw.)
>
> Have we had a wraparound yet?
Just for the record, I had an OID overflow on production database (most middleware crashed mysteriously but no severe data loss) about a month ago. This was on 7.0.2 which probably had some bug ... preventing real wrap to happen. No new allocations (INSERTs that used autoincrementing sequences) were possible in most tables.
Anyway, I had to dump/restore the database - several hours downtime. The database is not very big in size (around 10 GB in the data directory), but contains many objects (logs) and many objects are inserted/deleted from the database - in my opinion at not very high rate. Many tables are also created/dropped during processing.
What is worrying is that this database lived about half a year only...
In my opinion, making OIDs optional would help things very much. In my case, I don't need OIDs for log databases. Perhaps it would additionally help if OIDs are separately increasing for each database - not single counter for the entire PostgreSQL installation.
Regards,
Daniel
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2001-07-19 13:07:15 | Re: pg_depend |
Previous Message | Reinhard Max | 2001-07-19 10:44:30 | Re: libpgtcl doesn't use UTF encoding of TCL |