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.
