| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fsync request queue |
| Date: | 2018-04-30 23:07:48 |
| Message-ID: | CAH2-Wzn+vxv4Ct2PveVhPqqRb65v1w5OzPm=8vA4=fM16A7dBA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Apr 30, 2018 at 4:03 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> Is this a problem in practice, though? I don't remember seeing any reports
>> of the fsync queue filling up, after we got the code to compact it. I don't
>> know if anyone has been looking for that, so that might also explain the
>> absence of reports, though.
>
> It's probably hard to diagnose that as the origin of slow IO from the
> outside. It's not exactly easy to diagnose that even if you know what's
> going on.
True, but has anyone ever actually observed a non-zero
pg_stat_bgwriter.buffers_backend_fsync in the wild after the
compaction queue stuff was added/backpatched?
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yuriy Zhuravlev | 2018-04-30 23:08:03 | Re: Issues while building PG in MS Windows, using MSYS2 and MinGW-w64 |
| Previous Message | Andres Freund | 2018-04-30 23:03:21 | Re: Fsync request queue |