From: | José Luis Tallón <jltallon(at)adv-solutions(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | 'Robert Haas' <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: multixacts woes |
Date: | 2015-05-10 16:41:08 |
Message-ID: | 554F8A24.6070900@adv-solutions.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/08/2015 09:57 PM, Josh Berkus wrote:
> [snip]
>> It's certainly possible to have workloads triggering that, but I think
>> it's relatively uncommon. I in most cases I've checked the multixact
>> consumption rate is much lower than the xid consumption. There are some
>> exceptions, but often that's pretty bad code.
> I have a couple workloads in my pool which do consume mxids faster than
> xids, due to (I think) execeptional numbers of FK conflicts. It's
> definitely unusual, though, and I'm sure they'd rather have corruption
> protection and endure some more vacuums.
Seen corruption happen recently with OpenBravo on PostgreSQL 9.3.6
(Debian; binaries upgraded from 9.3.2) in a cluster pg_upgraded from 9.2.4
(albeit with quite insufficient autovacuum / poorly configured Postgres)
I fear that this might be more widespread than we thought, depending on
the exact workload/activity pattern.
If it would help, I can try to get hold of a copy of the cluster in
question (if the customer keeps any copy at all)
> If we do this, though, it
> might be worthwhile to backport the multixact age function, so that
> affected users can check and schedule mxact wraparound vacuums
> themselves, something you currently can't do on 9.3.
Thanks,
J.L.
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2015-05-10 17:40:12 | Re: multixacts woes |
Previous Message | Tom Lane | 2015-05-10 16:09:41 | Re: Manipulating complex types as non-contiguous structures in-memory |