Re: pg_restore and transaction id wraparound

A long time ago, in a galaxy far, far away, oneway_111(at)yahoo(dot)com (ow) wrote:
> --- Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)~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.