Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
От | Alvaro Herrera |
---|---|
Тема | Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 |
Дата | |
Msg-id | 20150608172332.GK133018@postgresql.org обсуждение исходный текст |
Ответ на | Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access
status of transaction 1
Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 |
Список | pgsql-hackers |
Andres Freund wrote: > On June 8, 2015 7:06:31 PM GMT+02:00, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > >I might be misreading the code, but PMSIGNAL_START_AUTOVAC_LAUNCHER > >only causes things to happen (i.e. a new worker to be started) when > >autovacuum is disabled. If autovacuum is enabled, postmaster > >receives the signal and doesn't do anything about it, because the > >launcher is already running. Of course, regularly scheduled autovac > >workers will eventually start running, but perhaps this is not good > >enough. > > Well that's just the same for the plain xid precedent? I'd not mind > improving further, but that seems like a separate thing. Sure. I just concern that we might be putting excessive trust on emergency workers being launched at a high pace. With normally configured systems (naptime=1min) it shouldn't be a problem, but we have seen systems with naptime set to one hour or so, and those might feel some pain; and it would get worse the more databases you have, because people might feel the need to space the autovac runs even more. (My personal alarm bells go off when I see autovac_naptime=15min or more, but apparently not everybody sees things that way.) > --- > Please excuse brevity and formatting - I am writing this on my mobile phone. I wonder if these notices are useful at all. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: