| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Tianzhou Chen <tianzhouchen(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Challenges preventing us moving to 64 bit transaction id (XID)? |
| Date: | 2017-06-07 17:08:39 |
| Message-ID: | CA+TgmobYHmh6oCJqe9eG1BPBh4FaYVx5xNDMmCATto7H-ED87w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 7, 2017 at 12:49 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2017-06-07 07:49:00 -0300, Alvaro Herrera wrote:
>> Instead of adding a second 64 bit counter for multixacts, how about
>> first implementing something like TED which gets rid of multixacts (and
>> freezing thereof) altogether?
>
> -1 - that seems like a too high barrier. We've punted on improvements on
> this because of CSN, xid-lsn ranges, and at some point we're going to
> have to make pragmatic choices, rather than strive for something more ideal.
What is the problem that we are trying to solve with this change? Is
there a practical use case for setting autovacuum_freeze_max_age >
2000000000, or is this just so that when autovacuum fails to vacuum
things in time, we can bloat clog instead of performing an emergency
shutdown?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-06-07 17:12:02 | Re: HACKERS[PROPOSAL] split ProcArrayLock into multiple parts |
| Previous Message | Robert Haas | 2017-06-07 17:07:10 | Re: BEFORE trigger can cause undetected partition constraint violation |