Re: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
| От | Bruce Momjian |
|---|---|
| Тема | Re: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 |
| Дата | |
| Msg-id | 20150529194953.GC16602@momjian.us обсуждение |
| Ответ на | Re: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access
status of transaction 1
Re: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 |
| Список | pgsql-hackers |
On Thu, May 28, 2015 at 07:24:26PM -0400, Robert Haas wrote: > On Thu, May 28, 2015 at 4:06 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > > FTR: Robert, you have been a Samurai on this issue. Our many thanks. > > Thanks! I really appreciate the kind words. > > So, in thinking through this situation further, it seems to me that > the situation is pretty dire: > > 1. If you pg_upgrade to 9.3 before 9.3.5, then you may have relminmxid > or datminmxid values which are 1 instead of the correct value. > Setting the value to 1 was too far in the past if your MXID counter is > < 2B, and too far in the future if your MXID counter is > 2B. > > 2. If you pg_upgrade to 9.3.7 or 9.4.2, then you may have datminmxid > values which are equal to the next-mxid counter instead of the correct > value; in other words, they are two new. > > 3. If you pg_upgrade to 9.3.5, 9.3.6, 9.4.0, or 9.4.1, then you will > have the first problem for tables in template databases, and the > second one for the rest. (See 866f3017a.) I think we need to step back and look at the brain power required to unravel the mess we have made regarding multi-xact and fixes. (I bet few people can even remember which multi-xact fixes went into which releases --- I can't.) Instead of working on actual features, we are having to do this complex diagnosis because we didn't do a thorough analysis at the time a pattern of multi-xact bugs started to appear. Many projects deal with this compound bug debt regularly, but we have mostly avoided this fate. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-hackers по дате отправления: