[HACKERS] PANIC: invalid index offnum: 186 when processing BRIN indexes inVACUUM

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема [HACKERS] PANIC: invalid index offnum: 186 when processing BRIN indexes inVACUUM
Дата
Msg-id 10d2b9f9-f427-03b8-8ad9-6af4ecacbee9@2ndquadrant.com
обсуждение исходный текст
Ответы [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes inVACUUM  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
Hi,

while doing some weekend hacking & testing on the BRIN patches I posted
recently, I ran into PANICs in VACUUM, when it summarizes data inserted
concurrently (in another session):

    PANIC:  invalid index offnum: 186

Initially I thought it's a bug in my patches, but apparently it's not
and I can reproduce it easily on current master (846fcc8516).

I'm not sure if/how this is related to the BRIN autosummarization issue
reported by Justin Pryzby about two weeks ago (thread [1]), but I don't
see any segfaults and the messages are always exactly the same.

[1]
https://www.postgresql.org/message-id/flat/20171014035732.GB31726%40telsasoft.com

Reproducing the issue is simple:

    create table brin_test (a int, b bigint, c float,
                            d double precision, e uuid);
    create index on brin_test using brin (a);
    create index on brin_test using brin (b);
    create index on brin_test using brin (c);
    create index on brin_test using brin (d);
    create index on brin_test using brin (e);

and then run

    insert into brin_test select
         mod(i,100000)/25,
         mod(i,100000)/25,
         mod(i,100000)/25,
         mod(i,100000)/25,
        md5((mod(i,100000)/25)::text)::uuid
    from generate_series(1,100000) s(i) \watch 0.1

    vacuum brin_test \watch 1

And sooner or later (for me it only takes a minute or two in most cases)
the VACUUM session should fail with the PANIC message mentioned above.
It always fails with the message, only the value (offset) changes.

The stack trace always looks exactly the same - see the attachment.

At first it seemed the idxrel is always the index on 'e' (i.e. the UUID
column), but it seems I also got failures on the other indexes.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Вложения

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Parallel safety for extern params
Следующее
От: David Fetter
Дата:
Сообщение: Re: [HACKERS] Jsonb transform for pl/python