> On Thu, Mar 7, 2019 at 10:24 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > So if we think we can invent a "MAGICALLY FIX MY DATABASE" command, > > let's do that. But please let's not turn a well defined command > > like VACUUM into something that you don't quite know what it will do.
I see your point. Another approach would be to let user know what prevents VACUUM to fix the wraparound in single mode, mainly that there are orphan temp tables . But it might be too verbose if PostgreSQL will print warning for every orphan temp table. > Really, I'd like to redesign the way this whole system works. Instead > of forcing a full-system shutdown, we should just refuse to assign any > more XIDs, disable the vacuum cost delay machinery, and let autovacuum > go nuts until the problem is corrected. Forcing people to run vacuum > to run one vacuum at a time is not nice, and not having background > processes like the bgwriter or checkpointer while you're doing it > isn't good either, and there's no good reason to disallow SELECT > queries while we're recovering the system either. Actually, even > before we get to the point where we currently force a shutdown, we > ought to just give up on vacuum cost delay, either all at once or > perhaps incrementally, when we see that we're getting into trouble. > But all of that is work for another time. I think it would be very neat feature! -- Arthur Zakirov Postgres Professional: http://www.postgrespro.com Russian Postgres Company
