Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fugP1-0007dh-K1 for pgsql-admin@arkaria.postgresql.org; Tue, 28 Aug 2018 15:59:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fugOz-0004RG-EF for pgsql-admin@arkaria.postgresql.org; Tue, 28 Aug 2018 15:59:33 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fugOz-0004R8-1f for pgsql-admin@lists.postgresql.org; Tue, 28 Aug 2018 15:59:33 +0000 Received: from st14p37im-asmtp001.me.com ([17.41.209.30]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fugOv-0001ay-IH for pgsql-admin@lists.postgresql.org; Tue, 28 Aug 2018 15:59:31 +0000 Received: from process-dkim-sign-daemon.st14p37im-asmtp001.me.com by st14p37im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PE600800HJSXL00@st14p37im-asmtp001.me.com> for pgsql-admin@lists.postgresql.org; Tue, 28 Aug 2018 15:59:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=04042017; t=1535471968; bh=arfDCKkM1ilbqaBEby5OSNI/r46Ir67xd5I7fC7QOJs=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=AAbWdndfvy7Mxmxqy2pdz6DHWtA27TXXKVWW3JGnMkCz4kDWhn63hnYgErRiGSj9x qjAoD/n0rUS09ae844ccWCUI4Kg60BYnc/ZZMNwgmZWwx1LzgvaDCN+fNbxk5mZU9U UEOYMZQ9EBKHhhidBuPD8syYaqOBIlQFmo63+OkoEBWc5e8+dlcdeGxehHKfOoAHXK YupVYyRsM7aAS486lWnvV70R1Q4x2+3Et+vrFQqZeH35N4C/0pJXkbD+735KdGIgK/ hWLyxSHRto3dXhvtT6qzCurrPXL1fURAV1kNLY0fs1VYYkZL+NkYp9cSDyyTlmcsFX cKSY8T0tpx3eQ== Received: from icloud.com ([127.0.0.1]) by st14p37im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PE600A7RHR0UE00@st14p37im-asmtp001.me.com>; Tue, 28 Aug 2018 15:59:25 +0000 (GMT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1808280162 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-08-28_06:,, signatures=0 From: Evan Bauer Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_EC1D6EB9-8F1F-43BB-B9E7-D97468228E80" MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: tuple concurrently updated Date: Tue, 28 Aug 2018 11:59:23 -0400 In-reply-to: <9df8bb7f-50c4-ba3d-1086-d3871ad3f363@posteo.de> Cc: pgsql-admin@lists.postgresql.org To: Walter Nordmann 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> <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> X-Mailer: Apple Mail (2.3445.9.1) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --Apple-Mail=_EC1D6EB9-8F1F-43BB-B9E7-D97468228E80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 =E2=80=94 a = fascinating project =E2=80=94 thanks. Cheers, - Evan Evan Bauer eb@evanbauer.com +1 646 641 2973 Skype: evanbauer > On Aug 28, 2018, at 09:58, Walter Nordmann = wrote: >=20 > 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. >=20 > because there was a crash before, it must be a data corruption = problem, > not programming error. >=20 > regards >=20 > walter >=20 >=20 >=20 > Am 28.08.2018 um 15:45 schrieb pavan95: >> Hi Walter, >>=20 >> Why can't you go with a postgres service restart in order to get rid = of this >> error? >>=20 >>> DELETE FROM planet_osm_line WHERE osm_id =3D -166570;=20 >>> FEHLER: tuple concurrently updated=20 >> 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. >>=20 >> To defend against this race condition, lock the rows in the SELECT = with FOR >> UPDATE (or other options) >>=20 >> Regards, >> Pavan >>=20 >>=20 >>=20 >> -- >> Sent from: = http://www.postgresql-archive.org/PostgreSQL-admin-f2076596.html >>=20 >=20 >=20 --Apple-Mail=_EC1D6EB9-8F1F-43BB-B9E7-D97468228E80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 =E2=80=94 a fascinating project =E2=80=94 = 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 =3D -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.htm= l




= --Apple-Mail=_EC1D6EB9-8F1F-43BB-B9E7-D97468228E80--