Re: [PROPOSAL] Drop orphan temp tables in single-mode
От | Arthur Zakirov |
---|---|
Тема | Re: [PROPOSAL] Drop orphan temp tables in single-mode |
Дата | |
Msg-id | CAKNkYnz-7EuuQyk33HSvQui64+bhD-H9MrNDvA1d2RDRtfWM7A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] Drop orphan temp tables in single-mode (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: