Re: ERROR: found multixact from before relminmxid

Поиск
Список
Период
Сортировка
От Jeremy Finzel
Тема Re: ERROR: found multixact from before relminmxid
Дата
Msg-id CAMa1XUhoxkrq_XWqAEzK4Kzmg+amARsaaVJn-bZx4t9vRYPBzQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ERROR: found multixact from before relminmxid  (Alexandre Arruda <adaldeia@gmail.com>)
Ответы Re: ERROR: found multixact from before relminmxid
Список pgsql-general
Дерево обсуждения
On Tue, Jun 5, 2018 at 8:42 PM, Alexandre Arruda <adaldeia@gmail.com> wrote:
Em seg, 28 de mai de 2018 às 16:44, Andres Freund <andres@anarazel.de> escreveu:
>
> Hi,
>
> I think I found the bug, and am about to post a fix for it belo
> https://postgr.es/m/20180525203736.crkbg36muzxrjj5e@alap3.anarazel.de.
>
> Greetings,
>
> Andres Freund

Hi Andres,

In end of April we did a complete dump/reload in database to version 10.3.
Today, the problem returns:

production=# vacuum verbose co27t;
INFO:  vacuuming "public.co27t"
ERROR:  found multixact 81704071 from before relminmxid 107665371
production=# vacuum full verbose co27t;
INFO:  vacuuming "public.co27t"
ERROR:  found multixact 105476076 from before relminmxid 107665371
production=# cluster co27t;
ERROR:  found multixact 105476076 from before relminmxid 107665371

But this time, regular vacuum versus full/cluster are different in
multixact number.
Your patch is applicable to this issue and is in 10.4 ?

Best regards,

Alexandre


We encountered this issue ourselves for the first time on a busy OLTP system.  It is at 9.6.8.  We found that patching to 9.6.9 on a snapshot of this system did not fix the problem, but I assume that is because the patch in 9.6.9 only prevents the problem moving forward.  Is that accurate?

Before we take an outage for this patch, we want as much information as possible on if this is indeed likely to be our issue.

Like the other people on this thread, amcheck didn't show anything on the snap:
db=# select bt_index_parent_check(indexrelid,true) FROM pg_stat_user_indexes WHERE relname = 'mytable';
 bt_index_parent_check
-----------------------





(5 rows)

db=# select bt_index_check(indexrelid,true) FROM pg_stat_user_indexes WHERE relname = 'mytable';
 bt_index_check
----------------





(5 rows)


Not surprisingly, I can get the problem to go away in production if I use pg_repack to rebuild the table.  But we are interested of course in solving this problem permanently.

Thanks,
Jeremy

В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: (2^63 - 1)::bigint => out of range? (because of the doubleprecision)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: (2^63 - 1)::bigint => out of range? (because of the double precision)