Re: Enabling autovacuum by default (was Re: [HACKERS] Autovacuum improvements)
Alvaro Herrera <[EMAIL PROTECTED]> writes: > With that taken care of, do I dare propose enabling autovacuum by > default, so that further changes will be picked up quickly by the > buildfarm? Sure, let's try it and see what else breaks ;-) regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: Enabling autovacuum by default (was Re: [HACKERS] Autovacuum
Andrew Dunstan wrote: > Alvaro Herrera wrote: > >Tom Lane wrote: > > > > > >>Actually the reason it's not enabled by default today has nothing to do > >>with either of those; it's > >> > >>3. Unexpected side effects on foreground processes, such as surprising > >>failures of DROP DATABASE commands. (See archives for details.) > >> > >>Until (3) is addressed I don't think there is any chance of having > >>autovac on by default, and so worrying about (1) and (2) seems a bit > >>premature. Or at least, if you want to work on those fine, but don't > >>expect that it will alter the fact that the factory default is "off". > >> > > > >With that taken care of, do I dare propose enabling autovacuum by > >default, so that further changes will be picked up quickly by the > >buildfarm? > > I should have thought most autovacuum problems would only become evident > after significant running time, while buildfarm runs are quite short. Well, the last time we enabled autovacuum by default (during 8.2's beta period) there were some buildfarm failures right away, which is why it was disabled. On the other hand, it will help uncover possible portability problems in the code that will be newly written. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: Enabling autovacuum by default (was Re: [HACKERS] Autovacuum
Alvaro Herrera wrote: Tom Lane wrote: Actually the reason it's not enabled by default today has nothing to do with either of those; it's 3. Unexpected side effects on foreground processes, such as surprising failures of DROP DATABASE commands. (See archives for details.) Until (3) is addressed I don't think there is any chance of having autovac on by default, and so worrying about (1) and (2) seems a bit premature. Or at least, if you want to work on those fine, but don't expect that it will alter the fact that the factory default is "off". With that taken care of, do I dare propose enabling autovacuum by default, so that further changes will be picked up quickly by the buildfarm? I should have thought most autovacuum problems would only become evident after significant running time, while buildfarm runs are quite short. Of course, some will be apparent right away. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
