Re: tuple concurrently updated

Walter,

I agree with your diagnosis of a database corruption, the error message from your attempt to dump essentially provides it:
pg_dump: Fehlermeldung vom Server: FEHLER: unexpected chunk number 0
(expected 1) for toast value 1261719035 in pg_toast_1340113

With all of the TEXT columns in the table, a corrupted TOAST pointer or (more likely) TOAST table page looks to be the culprit.

I agree that a rebuild seems to be the best (though lengthy) approach.

Your post here was my first introduction to Open Street Map — a fascinating project — thanks.

Cheers,

- Evan

Evan Bauer
eb(at)evanbauer(dot)com
+1 646 641 2973
Skype: evanbauer

> On Aug 28, 2018, at 09:58, Walter Nordmann <walter(dot)nordmann(at)posteo(dot)de> wrote:
>
> updates are done using a program, that is without my control: osm2pgsql.
> this program does everthing which is necessary including locking. and
> it't running for years on many, many openstreetmap servers.
>
> because there was a crash before, it must be a data corruption problem,
> not programming error.
>
> regards
>
> walter
>
>
>
> Am 28.08.2018 um 15:45 schrieb pavan95:
>> Hi Walter,
>>
>> Why can't you go with a postgres service restart in order to get rid of this
>> error?
>>
>>> DELETE FROM planet_osm_line WHERE osm_id = -166570;
>>> FEHLER: tuple concurrently updated
>> Concurrent transactions can update or delete one or more of those rows
>> before DELETE can lock the rows (at least with the default isolation level
>> READ COMMITTED). This would result in your error message.
>>
>> To defend against this race condition, lock the rows in the SELECT with FOR
>> UPDATE (or other options)
>>
>> Regards,
>> Pavan
>>
>>
>>
>> --
>> Sent from: http://www.postgresql-archive.org/PostgreSQL-admin-f2076596.html
>>
>
>