On 1/20/17 12:40 AM, Amit Khandekar wrote:
My impression was that postmaster is supposed to just do a minimal
work of starting auto-vacuum launcher if not already. And, the work of
ensuring all the things keep going is the job of auto-vacuum launcher.
There's already a ton of logic in the launc
On Fri, Jan 20, 2017 at 2:43 AM, Michael Paquier
wrote:
> On Fri, Jan 20, 2017 at 4:11 AM, Alvaro Herrera
> wrote:
>> Robert Haas wrote:
>>
>>> After sleeping on this, I'm inclined to go with Amit's fix for now.
>>> It seems less likely to break anything in the back-branches than any
>>> other op
On Fri, Jan 20, 2017 at 4:11 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>
>> After sleeping on this, I'm inclined to go with Amit's fix for now.
>> It seems less likely to break anything in the back-branches than any
>> other option I can think up.
>
> Yeah, no objections here.
+1.
--
Michae
On 18 January 2017 at 02:32, Robert Haas wrote:
> On Fri, Jan 13, 2017 at 8:45 AM, Alvaro Herrera
> wrote:
>> I think this is the same problem as reported in
>> https://www.postgresql.org/message-id/CAMkU=1yE4YyCC00W_GcNoOZ4X2qxF7x5DUAR_kMt-Ta=ypy...@mail.gmail.com
>
> If I understand correctly,
Robert Haas wrote:
> After sleeping on this, I'm inclined to go with Amit's fix for now.
> It seems less likely to break anything in the back-branches than any
> other option I can think up.
Yeah, no objections here.
Note typo "imporatant" in the comment.
--
Álvaro Herrerahttps
On Tue, Jan 17, 2017 at 4:02 PM, Robert Haas wrote:
> Amit's chosen yet another possible place to insert the guard: teach
> autovacuum that if a worker skips at least one table due to concurrent
> autovacuum activity AND ends up vacuuming no tables, don't call
> vac_update_datfrozenxid(). Since t
On Fri, Jan 13, 2017 at 8:45 AM, Alvaro Herrera
wrote:
> Amit Khandekar wrote:
>> In a server where autovacuum is disabled and its databases reach
>> autovacuum_freeze_max_age limit, an autovacuum is forced to prevent
>> xid wraparound issues. At this stage, when the server is loaded with a
>> lot
On 16 January 2017 at 15:54, Masahiko Sawada wrote:
> Since autovacuum worker wakes up autovacuum launcher after launched
> the autovacuum launcher could try to spawn worker process at high
> frequently if you have database with very large table in it that has
> just passed autovacuum_freeze_max_a
On Mon, Jan 16, 2017 at 1:50 PM, Amit Khandekar wrote:
> On 13 January 2017 at 19:15, Alvaro Herrera wrote:
>> I think this is the same problem as reported in
>> https://www.postgresql.org/message-id/CAMkU=1yE4YyCC00W_GcNoOZ4X2qxF7x5DUAR_kMt-Ta=ypy...@mail.gmail.com
>
> Ah yes, this is the same p
On 13 January 2017 at 19:15, Alvaro Herrera wrote:
> I think this is the same problem as reported in
> https://www.postgresql.org/message-id/CAMkU=1yE4YyCC00W_GcNoOZ4X2qxF7x5DUAR_kMt-Ta=ypy...@mail.gmail.com
Ah yes, this is the same problem. Not sure why I didn't land on that
thread when I tried
Amit Khandekar wrote:
> In a server where autovacuum is disabled and its databases reach
> autovacuum_freeze_max_age limit, an autovacuum is forced to prevent
> xid wraparound issues. At this stage, when the server is loaded with a
> lot of DML operations, an exceedingly high number of autovacuum
>
11 matches
Mail list logo
