Hi Chris,
> XID wraparound doesn't happen to healthy databases
> If you disagree, I would like to hear why.
Consider the case when you run a slow OLAP query that takes 12h to
complete and 100K TPS of fast OLTP-type queries on the same system.
The fast queries will consume all 32-bit XIDs in less than 12 hours,
while the OLAP query started 12 hours ago didn't finish yet and thus
its tuples can't be frozen.
> I agree that 64-bit xids are a good idea. I just don't think that existing safety measures should be ignored or
reverted.
Fair enough.
> The problem isn't just the lack of disk space, but the difficulty that stuck autovacuum runs pose in resolving the
issue. Keep in mind that everything you can do to reclaim disk space (vacuum full, cluster, pg_repack) will be
significantlyslowed down by an extremely bloated table/index comparison. The problem is that if you are running out of
diskspace, and your time to recovery much longer than expected, then you have a major problem. It's not just one or
theother, but the combination that poses the real risk here.
>
> Now that's fine if you want to run a bloatless table engine but to my knowledge none of these are production-ready
yet. ZHeap seems mostly stalled. Oriole is still experimental. But with the current PostgreSQL table structure.
>
> A DBA can monitor disk space, but if the DBA is not also monitoring xid lag, then by the time corrective action is
takenit may be too late.
Good point but I still don't think this is related to the XID
wraparound problem.
--
Best regards,
Aleksander Alekseev