Re: ERROR: found multixact from before relminmxid
От | Andres Freund |
---|---|
Тема | Re: ERROR: found multixact from before relminmxid |
Дата | |
Msg-id | 9590F65E-174C-4432-AC5B-9D5B005D59EE@anarazel.de обсуждение исходный текст |
Ответ на | Re: ERROR: found multixact from before relminmxid (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: ERROR: found multixact from before relminmxid
|
Список | pgsql-general |
On April 9, 2018 7:51:19 PM PDT, Peter Geoghegan <pg@bowt.ie> wrote: >On Mon, Apr 9, 2018 at 6:56 PM, Alexandre Arruda <adaldeia@gmail.com> >wrote: >> (... and all other indexes returns null too) >> >> I tried with bt_index_check too. Same results. > >That's interesting, because it tells me that you have a table that >appears to not be corrupt, despite the CLUSTER error. Also, the error >itself comes from sanity checking added to MultiXact freezing fairly >recently, in commit 699bf7d0. > >You didn't say anything about regular VACUUM being broken. Do you find >that it works without any apparent issue? > >I have a suspicion that this could be a subtle bug in >CLUSTER/freezing. The only heap_freeze_tuple() caller is code used by >CLUSTER, so it's not that hard to imagine a MultiXact freezing bug >that is peculiar to CLUSTER. Though I haven't thought about it in much >detail. I've not followed this thread. Possible it's the overeager check for pg upgraded tuples from before 9.3 that Alvaro fixedrecently? Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
В списке pgsql-general по дате отправления: