Re: pg_restore and transaction id wraparound
| От | Christopher Browne |
|---|---|
| Тема | Re: pg_restore and transaction id wraparound |
| Дата | |
| Msg-id | m3isl2bssb.fsf@wolfe.cbbrowne.com обсуждение исходный текст |
| Ответ на | Re: pg_restore and transaction id wraparound (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | 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 по дате отправления: