From: Evan Bauer <evanbauer@mac.com>
To: Walter Nordmann <walter.nordmann@posteo.de>
Cc: pgsql-admin@lists.postgresql.org
Subject: Re: tuple concurrently updated
Date: Tue, 28 Aug 2018 11:59:23 -0400
Message-ID: <B8125B40-EB95-4E5B-AF6F-9C95214E90D2@mac.com> (raw)
In-Reply-To: <9df8bb7f-50c4-ba3d-1086-d3871ad3f363@posteo.de>
References: <986488f7-ff29-5dff-9425-5fcd6dcbb68a@posteo.de>
<1378566276.366027624.1535454005687.JavaMail.root@zimbra82-e14.priv.proxad.net>
<99342cd8-c2f6-31bd-f8e4-5c65658b1a2f@posteo.de>
<1233975696.366149748.1535454938944.JavaMail.root@zimbra82-e14.priv.proxad.net>
<cc5734b5-7706-1873-4640-67c51a42cb23@posteo.de>
<f737db87-9ca8-a90c-c29d-fd9638a8a3cf@posteo.de>
<114865725.367018989.1535461805284.JavaMail.root@zimbra82-e14.priv.proxad.net>
<2be8ebca-fecc-51f4-39d7-9869941c679a@posteo.de>
<1535463942466-0.post@n3.nabble.com>
<9df8bb7f-50c4-ba3d-1086-d3871ad3f363@posteo.de>
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@evanbauer.com
+1 646 641 2973
Skype: evanbauer
> On Aug 28, 2018, at 09:58, Walter Nordmann <walter.nordmann@posteo.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
>>
>
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: evanbauer@mac.com, walter.nordmann@posteo.de, pgsql-admin@lists.postgresql.org
Subject: Re: tuple concurrently updated
In-Reply-To: <B8125B40-EB95-4E5B-AF6F-9C95214E90D2@mac.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox