Hi hackers, > > I have a very serious concern about the current patch set. as someone who > > has faced transaction id wraparound in the past. > > [...] > > I had a similar stance when I started working on this patch. Of > course, it seemed horrible just to postpone the consequences of > inadequate monitoring, too long running transactions that prevent > aggressive autovacuum etc. So I can understand your point. > > With time I've got to a little bit of another view of this feature i.e. > > 1. It's important to correctly set monitoring, the cut-off of long > transactions, etc. anyway. It's not the responsibility of vacuum > before wraparound to report inadequate monitoring etc. Furthermore, in > real life, this will be already too late if it prevents 32-bit > wraparound and invokes much downtime in an unexpected moment of time > if it occurs already. (The rough analogy for that is the machine > running at 120mph turns every control off and applies full brakes just > because the cooling liquid is low (of course there might be a warning > previously, but anyway)) > > 2. The checks and handlers for the event that is never expected in the > cluster lifetime (~200 years at constant rate of 1e6 TPS) can be just > dropped. Of course we still need to do automatic routine maintenance > like cutting SLRU buffers (but with a much bigger interval if we have > much disk space e.g.). But I considered that we either can not care > what will be with cluster after > 200 years (it will be migrated many > times before this, on many reasons not related to Postgres even for > the most conservative owners). So the radical proposal is to drop > 64-bit wraparound at all. The most moderate one is just not taking > very much care that after 200 years we have more hassle than next > month if we haven't set up everything correctly. Next month's pain > will be more significant even if it teaches dba something. > > Big thanks for your view on the general implementation of this feature, > anyway.
I'm inclined to agree with Pavel on this one. Keeping 32-bit XIDs in order to intentionally trigger XID wraparound to indicate the ending disk space and/or misconfigured system (by the time when it's usually too late anyway) is a somewhat arguable perspective. It would be great to notify the user about the potential issues with the configuration and/or the fact that VACUUM doesn't catch up. But it doesn't mean we should keep 32-bit XIDs in order to achive this. -- Best regards, Aleksander Alekseev
