Re: pg_restore and transaction id wraparound - Mailing list pgsql-admin

From Christopher Browne
Subject Re: pg_restore and transaction id wraparound
Date
Msg-id m3isl2bssb.fsf@wolfe.cbbrowne.com
Whole thread Raw
In response to Re: pg_restore and transaction id wraparound  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-admin
A long time ago, in a galaxy far, far away, oneway_111@yahoo.com (ow) wrote:
> --- Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Actually you can only have 4 billion SQL commands per xid, because the
>> CommandId datatype is also just 32 bits.  I've never heard of anyone
>> running into that limit, though.
>
> Perhaps noone yet had a table with 4B records in pgSql. Otherwise,
> how would they dump/restore it?

I may have been guilty of hyperbole, by using the number 10 billion,
but not of proving this impossible.

If you had a table that large, dump/restore wouldn't have any XID
problems because the normal dump/restore involves copying the data out
(ONE query, ONE XID), and then reading it via the COPY command (again,
ONE query, ONE XID).

And I think I would be quite displeased if I had a table with that
many records, in any case, because dump/restore would take an
enormously long time as would reindexing.
--
(format nil "~S@~S" "cbbrowne" "ntlug.org")
http://cbbrowne.com/info/linuxdistributions.html
16-inch Rotary Debugger: A highly effective tool for locating problems
in  computer   software.   Available   for  delivery  in   most  major
metropolitan areas.  Anchovies contribute to poor coding style.

pgsql-admin by date:

Previous
From: "Bryan Encina"
Date:
Subject: Re: db-recovery after update 7.1 -> 7.4 failed
Next
From: pginfo
Date:
Subject: compiling 7.4 --with-java