> On Thu, Mar 7, 2019 at 10:24 AM Tom Lane <tgl@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