Re: ERROR: posting list tuple with 20 items cannot be split at offset 168

From: Herman verschooten <Herman(at)verschooten(dot)net>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Christl Nagels <christel(dot)nagels(at)tranna(dot)be>
Subject: Re: ERROR: posting list tuple with 20 items cannot be split at offset 168
Date: 2021-10-26 05:35:18
Message-ID: 4F70DF51-FD72-41EC-9D7F-40C359AB3838@verschooten.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Peter,

Thanks for the info.
I don’t recall the exact 13 version we were on.

I can confirm that after dropping and recreating the 6 indexes everything is working fine.

Thanks for all the help, both here and on slack,

Herman

> Op 25 okt. 2021, om 17:29 heeft Peter Geoghegan <pg(at)bowt(dot)ie> het volgende geschreven:
>
> On Mon, Oct 25, 2021 at 2:59 AM Herman verschooten
> <Herman(at)verschooten(dot)net> wrote:
>> tranman_production=# update freights set cmr_received=false where id=49632;
>> ERROR: XX000: posting list tuple with 20 items cannot be split at offset 168
>> LOCATION: _bt_swap_posting, nbtdedup.c:1037
>>
>> If I drop the index index_freights_on_cmr_received, then the update succeeds.
>
> What you see here is a defensive "can't happen" error that I added in
> commit 8f72bbac, and backpatched to Postgres 13.4, which came out on
> 2021-08-12. The goal of that error is to make a possible hard crash
> due to corruption into a slightly friendlier kind of failure (the
> error that you see here). Were you running 13.4 before the upgrade?
>
> If you were on 13.3 or earlier before the upgrade to 14, then it's
> possible that the problem was there all along, but is only now visible
> for the first time.
>
> --
> Peter Geoghegan

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2021-10-26 06:03:54 Re: conchuela timeouts since 2021-10-09 system upgrade
Previous Message Masahiko Sawada 2021-10-26 05:06:23 Re: Logical replication - empty search_path bug?