|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 05/08/2015 09:57 PM, Josh Berkus wrote:
>> 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.
|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|