| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | 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, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: ERROR: found multixact from before relminmxid |
| Date: | 2018-04-10 02:51:19 |
| Message-ID: | CAH2-Wzn=Y3aY_2F21EWGYPonBjzMHb18wN_HND51hSD3BKGXdQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-04-10 02:53:23 | Re: ERROR: found multixact from before relminmxid |
| Previous Message | Alexandre Arruda | 2018-04-10 01:56:48 | Re: ERROR: found multixact from before relminmxid |