From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie>,Alexandre Arruda <adaldeia(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>,pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: ERROR: found multixact from before relminmxid |
Date: | 2018-04-10 02:53:23 |
Message-ID: | 9590F65E-174C-4432-AC5B-9D5B005D59EE@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On April 9, 2018 7:51:19 PM PDT, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>On Mon, Apr 9, 2018 at 6:56 PM, Alexandre Arruda <adaldeia(at)gmail(dot)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 fixed recently?
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2018-04-10 03:08:02 | Re: ERROR: found multixact from before relminmxid |
Previous Message | Peter Geoghegan | 2018-04-10 02:51:19 | Re: ERROR: found multixact from before relminmxid |