Re: [HACKERS] Non-transactional pg_class, try 2
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Non-transactional pg_class, try 2 |
Дата | |
Msg-id | 9109.1151539701@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Non-transactional pg_class, try 2 (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: [HACKERS] Non-transactional pg_class, try 2
Re: [HACKERS] Non-transactional pg_class, try 2 |
Список | pgsql-patches |
Alvaro Herrera <alvherre@commandprompt.com> writes: > This patch has the nasty side effect mentioned above -- people will have > to set template0 as connectable and manually run vacuum on it > periodically, unless they run autovacuum. That's pretty messy --- making template0 connectable is a great way to shoot yourself in the foot. What I'd propose instead is that even if autovacuum is nominally off, the system forces autovacuum when it notices that a non-connectable database is approaching wraparound. In this mode the autovac daemon would be restricted to processing non-connectable databases. (The subtext here is that autovac is the wave of the future anyway.) In fact, maybe we should just force an autovac cycle for any DB that appears to be approaching wraparound, rather than waiting for the shutdown-before-wraparound code to kick in. Getting into that state amounts to whacking DBAs upside the head for being stupid, which doesn't really win us any friends ... Implementation-wise, I'd propose that we add another PostmasterSignal event type whereby a backend could request the postmaster to launch an autovac process even if autovac is off. The end-of-VACUUM code that scans pg_database.datminxid would issue the signal if it finds anything seriously old. regards, tom lane
В списке pgsql-patches по дате отправления: