> Did you observe whether the vacuumed tables' relminmxid advance? If it
> didn't, then those vacuums are a waste of time.
>
> Note that freeze_table_age affects when vacuum does a full table scan
> vs. when it skips pages due to visibility map. A vacuum that does a
> partial scan does *not* adva
On 2018-Jun-14, Daniel Lagerman wrote:
> > Set vacuum_multixact_freeze_table_age to 0 (causing all vacuums to scan
> > tables fully) and vacuum_multixact_freeze_min_age to some value like one
> > million (so that they remove most of the oldest multixacts, leaving
> > just the frontmost one million
>
> Hello Daniel
>
> The advice from Lawrence downthread is very much on point. If you can
> upgrade to 9.5, do it. He mentions savepoints, but one more case is
> plpgsql blocks with EXCEPTION clauses.
>
Hello Álvaro,
Thanks I'll make sure of both even if I do not believe this is this case
eith
Hey Lawrence,
Thanks for the input, I will check if this is the case, I do not believe it
is but its worth checking out. To me it looks like normal inserts.
I think we were just insanely behind on the vacuum. I have another server,
same code for the App on top of the DB which does not have this is
Hello Daniel
The advice from Lawrence downthread is very much on point. If you can
upgrade to 9.5, do it. He mentions savepoints, but one more case is
plpgsql blocks with EXCEPTION clauses.
On 2018-Jun-13, Daniel Lagerman wrote:
> Hello Álvaro,
>
> I'm running at 9.4.3, I know its an older ve
Hey Daniel,
This may be entirely unrelated to your query, but we’ve previously experienced
issues with 9.4 and crazy multixact members growth.
After digging into the issue, we found the culprit was code that would perform
the following actions:
begin;
for query in many_queries:
savepoint ;
Hello Álvaro,
I'm running at 9.4.3, I know its an older version but upgrading it outside
the scope right now for various reasons.
Based on the settings I posted what would be your recommended settings
right now to resolve this situation?
Maintenance is limited to weekends as this is a database wh
On 2018-Jun-13, Daniel Lagerman wrote:
> Hello!
>
> I have a question where I'm trying to determine the seriousness of the
> problem.
What's your server version?
The way to reclaim members space is to move forwards the
pg_database.datminmxid value from the database where it is oldest; and
the w
