Re: Postgres crashes at memcopy() after upgrade to PG 13.

From: Avinash Kumar <avinash(dot)vallarapu(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Postgres crashes at memcopy() after upgrade to PG 13.
Date: 2021-03-16 12:01:29
Message-ID: CAN0Tujdxtrsewp_T=SiETSgmh6Dw1kUwjK=hHRxGOdj=T-B_pQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Mon, Mar 15, 2021 at 3:21 PM Avinash Kumar <avinash(dot)vallarapu(at)gmail(dot)com>
wrote:

> Hi,
>
> On Mon, Mar 15, 2021 at 1:18 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
>> On Mon, Mar 15, 2021 at 6:56 AM Avinash Kumar
>> <avinash(dot)vallarapu(at)gmail(dot)com> wrote:
>> > psql:amchecksql.sql:17: DEBUG: leaf block 1043751 of index
>> "idx_id_mtime" has no first data item
>>
>> That one is harmless.
>>
>> > And one error as follows.
>> >
>> > psql:amchecksql.sql:17: ERROR: down-link lower bound invariant
>> violated for index "some_other_index"
>>
>> That indicates corruption. Can you tie this back to the crash? Is it
>> the same index?
>>
> No, that's not the same index. The Index discussed in the previous
> messages shows the following output.
>
> DEBUG: verifying consistency of tree structure for index "idx_id_mtime"
> with cross-level checks
> DEBUG: verifying level 2 (true root level)
> DEBUG: verifying level 1
> DEBUG: verifying level 0 (leaf level)
> DEBUG: verifying that tuples from index "idx_id_mtime" are present in
> "player"
> DEBUG: finished verifying presence of 1966412 tuples from table "player"
> with bitset 29.89% set
> LOG: duration: 3341.755 ms statement: SELECT bt_index_parent_check(index
> => c.oid, heapallindexed => true), c.relname, c.relpages FROM pg_index i
> JOIN pg_opclass op ON i.indclass[0] = op.oid JOIN pg_am am ON op.opcmethod
> = am.oid JOIN pg_class c ON i.indexrelid = c.oid JOIN pg_namespace n ON
> c.relnamespace = n.oid WHERE am.amname = 'btree' AND c.relpersistence !=
> 't' AND c.relkind = 'i' AND i.indisready AND i.indisvalid AND indexrelid =
> 80774 AND n.nspname = 'public' ORDER BY c.relpages DESC;
> bt_index_parent_check | relname | relpages
> -----------------------+-----------------+----------
> | idx_id_mtime | 8439
> (1 row)
>
>
>> --
>> Peter Geoghegan
>>
>
>
> --
> Regards,
> Avi.
>

I am afraid that it looks to me like a deduplication bug but not sure how
this can be pin-pointed. If there is something I could do to determine
that, I would be more than happy.

--
Regards,
Avi

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2021-03-16 12:21:16 Re: WAL-files is not removing authomaticaly
Previous Message Andrus 2021-03-16 11:59:07 Re: SV: Log files polluted with permission denied error messages after every 10 seconds

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-03-16 12:13:03 Re: EXPLAIN/EXPLAIN ANALYZE REFRESH MATERIALIZED VIEW
Previous Message Peter Smith 2021-03-16 11:57:12 Re: pg_subscription - substream column?