From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: widen vacuum buffer counters |
Date: | 2020-01-31 21:10:50 |
Message-ID: | CAOBaU_YxtFrVp5PHNjeEdd05o9XUaAuF_P+Y_+NuBOoZBemq5w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 31, 2020 at 9:59 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>
> We recently noticed that vacuum buffer counters wraparound in extreme
> cases, with ridiculous results. Example:
>
> 2020-01-06 16:38:38.010 EST [45625-1] app= LOG: automatic vacuum of table "somtab.sf.foobar": index scans: 17
> pages: 0 removed, 207650641 remain, 0 skipped due to pins, 13419403 skipped frozen
> tuples: 141265419 removed, 3186614627 remain, 87783760 are dead but not yet removable
> buffer usage: -2022059267 hits, -17141881 misses, 1252507767 dirtied
> avg read rate: -0.043 MB/s, avg write rate: 3.146 MB/s
> system usage: CPU 107819.92s/2932957.75u sec elapsed 3110498.10 sec
>
> That's to be expected, as tables exist that are large enough for 4 billion
> buffer accesses to be a possibility. Let's widen the counters, as in the
> attached patch.
>
> I propose to backpatch this.
+1, and patch LGTM.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-01-31 21:20:36 | Re: unsupportable composite type partition keys |
Previous Message | Alvaro Herrera | 2020-01-31 20:59:26 | widen vacuum buffer counters |