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 > significantly slowed down by an extremely bloated table/index comparison. > The problem is that if you are running out of disk space, and your time to > recovery much longer than expected, then you have a major problem. It's not > just one or the other, 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 taken it may be too late. Good point but I still don't think this is related to the XID wraparound problem. -- Best regards, Aleksander Alekseev
