Re: maximum number of rows in table - what about oid limits?
От | Bruce Momjian |
---|---|
Тема | Re: maximum number of rows in table - what about oid limits? |
Дата | |
Msg-id | 200106110437.f5B4bMH18423@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: maximum number of rows in table - what about oid limits? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-sql |
> "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. I wonder is we should check the size of pg_log on startup and warn the administrator? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-sql по дате отправления: