Re: [HACKERS] Non-transactional pg_class, try 2 - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] Non-transactional pg_class, try 2
Date
Msg-id 9109.1151539701@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Non-transactional pg_class, try 2  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [HACKERS] Non-transactional pg_class, try 2  (Simon Riggs <simon@2ndquadrant.com>)
Re: [HACKERS] Non-transactional pg_class, try 2  (Alvaro Herrera <alvherre@commandprompt.com>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Non-transactional pg_class, try 2
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Non-transactional pg_class, try 2