| From: | Floris Van Nee <florisvannee(at)Optiver(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | RE: visibility map corruption |
| Date: | 2021-07-04 22:28:25 |
| Message-ID: | bbea09c93b76447aa0b95d89f7beac2d@opammb0562.comp.optiver.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> I wonder if it's related to this issue:
>
> https://www.postgresql.org/message-
> id/20210423234256(dot)hwopuftipdmp3okf(at)alap3(dot)anarazel(dot)de
>
> Have you increased autovacuum_freeze_max_age from its default? This
> already sounds like the kind of database where that would make sense.
>
autovacuum_freeze_max_age is increased in our setup indeed (it is set to 500M). However, we do regularly run manual VACUUM (FREEZE) on individual tables in the database, including this one. A lot of tables in the database follow an INSERT-only pattern and since it's not running v13 yet, this meant that these tables would only rarely be touched by autovacuum. Autovacuum would sometimes kick in on some of these tables at the same time at unfortunate moments. Therefore we have some regular job running that VACUUM (FREEZE)s tables with a xact age higher than a (low, 10M) threshold ourselves.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2021-07-05 01:31:54 | Re: Disable WAL logging to speed up data loading |
| Previous Message | Justin Pryzby | 2021-07-04 22:22:59 | Re: "debug_invalidate_system_caches_always" is too long |