Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: BUG #16036: Segmentation fault while doing an update
From: =?utf-8?B?0JDQvdGC0L7QvSDQktC70LDRgdC+0LI=?= <druidvav@gmail.com>
In-Reply-To: <A1695349-530C-4871-AED5-0262A9BC9920@anarazel.de>
Date: Fri, 4 Oct 2019 04:24:24 +0300
Cc: pgsql-bugs@lists.postgresql.org,
 PG Bug reporting form <noreply@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C2DA3A10-8D6F-4EC0-9A24-58F5480FCF85@gmail.com>
References: <16036-28184c90d952fb7f@postgresql.org>
 <4E1FB33C-7280-487B-B3D1-D3C247AA9E3D@anarazel.de>
 <FBA5344D-9356-49BA-9B47-C3705C2E9481@gmail.com>
 <A1695349-530C-4871-AED5-0262A9BC9920@anarazel.de>
To: Andres Freund <andres@anarazel.de>
Precedence: bulk

Hello,

This test script always causes a crash:

postgres@gp-app01:~$ cat test.sh
psql -d gdeposylka -c "update tracking.test_session set list_position =3D =
list_position + 1 where id =3D 85638;" &
psql -d gdeposylka -c "update tracking.test_session set list_position =3D =
list_position + 1 where id =3D 85638;" &
psql -d gdeposylka -c "update tracking.test_session set list_position =3D =
list_position + 1 where id =3D 85638;" &
psql -d gdeposylka -c "update tracking.test_session set list_position =3D =
list_position + 1 where id =3D 85638;" &
psql -d gdeposylka -c "update tracking.test_session set list_position =3D =
list_position + 1 where id =3D 85638;" &
psql -d gdeposylka -c "update tracking.test_session set list_position =3D =
list_position + 1 where id =3D 85638;" &
psql -d gdeposylka -c "update tracking.test_session set list_position =3D =
list_position + 1 where id =3D 85638;" &

create table tracking.test_result
(
	id serial not null
		constraint test_result_pkey
			primary key,
	session_id integer
		constraint test_result_session_id_fkey
			references tracking.test_session,
	reported_at timestamp(0) default now(),
	courier varchar(25) not null,
	tracking_number varchar(60) not null,
	status varchar(25) not null,
	fail_combo integer default 0 not null,
	response_test text,
	response_real text,
	response_time real,
	code smallint,
	message text,
	retry integer
);

create index test_result_session_id_idx
	on tracking.test_result (session_id);

Didn=E2=80=99t finish isolating bug from my database so i=E2=80=99m not =
sure if it work out for you. Single queries work as usual, only =
concurrent ones cause crash.


> 4 =D0=BE=D0=BA=D1=82. 2019 =D0=B3., =D0=B2 4:20, Andres Freund =
<andres@anarazel.de> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):
>=20
> Hi,=20
>=20
> On October 3, 2019 6:14:33 PM PDT, "=D0=90=D0=BD=D1=82=D0=BE=D0=BD =
=D0=92=D0=BB=D0=B0=D1=81=D0=BE=D0=B2" <druidvav@gmail.com> wrote:
>> Hello,
>>=20
>> Looks like disabling jit didn=E2=80=99t affect backtrace at all:
>>=20
>> 0  GetMemoryChunkContext (pointer=3D0x0) at
>> ./build/../src/include/utils/memutils.h:127
>> #1  pfree (pointer=3D0x0) at
>> ./build/../src/backend/utils/mmgr/mcxt.c:1033
>> #2  0x0000555d7276aaca in heap_freetuple (htup=3D<optimized out>) at
>> ./build/../src/backend/access/common/heaptuple.c:1340
>> #3  0x0000555d72918889 in tts_buffer_heap_clear (slot=3D0x555d73dbb118)=

>> at ./build/../src/backend/executor/execTuples.c:652
>> #4  0x0000555d72918cbe in ExecClearTuple (slot=3D0x555d73dbb118) at
>> ./build/../src/include/executor/tuptable.h:428
>> #5  ExecResetTupleTable (tupleTable=3D0x555d73db5a10, =
shouldFree=3Dfalse)
>=20
> That's good - I was only looking at that because of the truncated =
backtrace. Did you do anything to make that work better this time?
>=20
> Are there any details that you can provide? Schema? Any extensions in =
use?=20
>=20
> Does the problem happen always, or just under concurrency?
>=20
> Andres
> --=20
> Sent from my Android device with K-9 Mail. Please excuse my brevity.