> No, it is not. The XID space is continuous and circular. For any given XID, there are 2^31-1 possible XIDs that are "before" it and 2^31-1 that are "after" it (plus the special > FrozenXID value, which is always before everything else). There's no absolute comparisons possible, only relative ones. Everything works without wraparound hiccups, because > the XID space has no endpoints. The price is that consistency is lost if there are ever XIDs in the system that are more than 2^31 transactions apart. We avoid that by replacing old > XIDs with FrozenXID before they get to be more than 2^31 transactions old. ..... > Actually, to compare two XIDs we just do a signed subtraction (ignoring > overflow) and see if the result is positive or negative. ...... Ok Thanks - If we could please continue this. Server version is 8.3.7 What I am trying to do is find out if/how we can speed up the autovacuum workers that are running on some really large tables and have been doing so for days. One of our large tables is currently being autovacuum'd and the autovac workers (to prevent wraparound) has been running for 7 days now. Linux (ps -alf) indicates it has only run up about 11m cpu time over 7 days. And I never see them active. So I don't know what the auto-vac workers are actually doing (except making my users nervous). Initially, we thought that a high value of pg_class.relfrozenid indicated that we were in danger of wraparound, but now, I realize that the age(relfrozenid) indicates that this is unlikely at this time (query below). # select relname, age(relfrozenxid), relfrozenxid FROM pg_class WHERE relkind = 'r' and relname = 'error'; relname | age | relfrozenxid ---------+-----------+-------------- error | 286569433 | 3781443077 autovacuum_freeze_max_age is the default of 200m, so I assume age(relfrozenid) triggered the autovac processing we are currently seeing? Also, maintenance_work_mem is 256MB. And the table size is 132GB. Should we increase maintenance_work_memory? if we increase maintenance_work_memory and reload, will the autovacuum workers pick up the change on the fly? I assume that killing the auto-vacuum workers is not a good idea? If we do, would auto-vac restart, with the increased memory allocation? Is there anything else I could be doing on-the-fly ? Mr -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
