From: | Alexandre Arruda <adaldeia(at)gmail(dot)com> |
---|---|
To: | adrien(dot)nayrat(at)anayrat(dot)info |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: ERROR: found multixact from before relminmxid |
Date: | 2018-11-07 12:21:57 |
Message-ID: | CAGewt-ukbL6WL8cc-G+iN9AVvmMQkhA9i2TKP4-6wJr6YOQkzA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
The best solution that I have found is kick all connections and execute a
select for update to /dev/null in the affected tables, i.e.:
psql -o /dev/null -c "select * from table for update" database
After this, the vacuum is executed w/o problems again.
Best regards,
Alexandre
Em qua, 7 de nov de 2018 às 10:05, Adrien NAYRAT <adrien(dot)nayrat(at)anayrat(dot)info>
escreveu:
> On 11/5/18 5:41 PM, Adrien NAYRAT wrote:
> > We "solved" with a dump/restore on another server, also we kept previous
> > cluster to investigate. I want to be sure we encountered the bug solved
> > in 9.6.9 and it is not a new one.
>
> FYI, I am not sure I will be able to keep previous cluster many days.
>
> >
> > If we confirm it, maybe we should advise users to perform integrity
> > check? I was surprised 9.6.9 avoid new appearance of corruption but
> > nothing to ensure if database is already corrupted.
>
> If I understand correctly, it seems related to vacuum skipping page
> already frozen. Maybe we should advise to do a VACUUM FREEZE with
> DISABLE_PAGE_SKIPPING option?
>
> Regards,
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Steven Winfield | 2018-11-07 12:38:44 | RE: why select count(*) consumes wal logs |
Previous Message | Adrien NAYRAT | 2018-11-07 12:05:15 | Re: ERROR: found multixact from before relminmxid |