Re: maximum number of rows in table - what about oid limits? - Mailing list pgsql-sql

From Jonathan Bartlett
Subject Re: maximum number of rows in table - what about oid limits?
Date
Msg-id Pine.LNX.4.21.0106071332360.781-100000@sdf.lonestar.org
Whole thread Raw
In response to Re: maximum number of rows in table - what about oid limits?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: maximum number of rows in table - what about oid limits?
Re: maximum number of rows in table - what about oid limits?
List pgsql-sql
Besides compatibility, what breaks when you make OIDs/Txn IDs
INT8s?  Maybe there should be a minor fork called Postgres64 which does
this for those needing large tables.  

Jon

johnnyb6@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

On Wed, 6 Jun 2001, Tom Lane wrote:

> "Josh Berkus" <josh@agliodbs.com> writes:
> > Given this, why bother with system-generated OIDs on user rows at all?
> > Why not simply reserve the OIDs for the system tables?
> 
> An option to not generate OIDs unless requested (on a table-by-table
> basis) has been discussed.  It seems like a fine near-term solution
> to me.  8-byte OIDs are a longer-term solution, because they'll break
> a lot of things (including clients...)
> 
> >> This is certainly not ideal, but it's not nearly as big a problem as
> >> transaction ID wraparound.  You can live with it, whereas right now
> >> xact ID wraparound is catastrophic.  That we gotta work on, soon.
> 
> > Nothing like reassuring us commercial DB users, Tom.  :-P
> > Can you describe what you're talking about?
> 
> It's in the archives: after 4G transactions, your database curls up
> and dies.  When your pg_log starts to approach 1Gbyte (2 bits per
> transaction) you'd better plan on dump/initdb/reload.
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
> 



pgsql-sql by date:

Previous
From: jdassen@cistron.nl (J.H.M. Dassen (Ray))
Date:
Subject: Re: About i8n
Next
From: Mark Stosberg
Date:
Subject: Re: behavior of ' = NULL' vs. MySQL vs. Standards