From: Tom Lane <tgl@sss.pgh.pa.us>
To: Guo Xiang Tan <gxtan1990@gmail.com>
cc: pgsql-bugs@lists.postgresql.org, Robert Haas <robertmhaas@gmail.com>
Subject: Re: BUG #15032: Segmentation fault when running a particular query
In-reply-to: 
 <CAEL+R-C0N+hM2OtE_s9xezy15w+18LOxgnYkjHh63SAi+3NxRA@mail.gmail.com>
References: <20180126074932.3098.97815@wrigleys.postgresql.org>
 <13015.1516992308@sss.pgh.pa.us>
 <CAEL+R-C0N+hM2OtE_s9xezy15w+18LOxgnYkjHh63SAi+3NxRA@mail.gmail.com>
Comments: In-reply-to Guo Xiang Tan <gxtan1990@gmail.com>
	message dated "Sat, 27 Jan 2018 07:46:23 +0800"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <19478.1517017305.0@sss.pgh.pa.us>
Date: Fri, 26 Jan 2018 20:42:47 -0500
Message-ID: <19519.1517017367@sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19478.1517017305.1@sss.pgh.pa.us>

Guo Xiang Tan <gxtan1990@gmail.com> writes:
>> Unsurprisingly, the given info is not enough to reproduce the crash.

> We could only reproduce this on our production PostgreSQL cluster.

Since the problem occurs during EvalPlanQual, it'd only manifest when
the update touched a concurrently-updated row, which is why it's hard
to reproduce if you aren't deliberately trying to trigger it.  But
I've been able to reproduce a crash at the same spot, and have made
a test case using the isolationtester infrastructure (attached).

I'll look into an actual fix tomorrow.

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="epq-mark-crash-test.patch";
	charset="us-ascii"
Content-ID: <19478.1517017305.2@sss.pgh.pa.us>
Content-Description: epq-mark-crash-test.patch
Content-Transfer-Encoding: quoted-printable

diff --git a/src/test/isolation/specs/eval-plan-qual.spec b/src/test/isola=
tion/specs/eval-plan-qual.spec
index 7ff6f6b..53a32e6 100644
*** a/src/test/isolation/specs/eval-plan-qual.spec
--- b/src/test/isolation/specs/eval-plan-qual.spec
*************** setup
*** 21,33 ****
   CREATE TABLE table_b (id integer, value text);
   INSERT INTO table_a VALUES (1, 'tableAValue');
   INSERT INTO table_b VALUES (1, 'tableBValue');
  }
  =

  teardown
  {
   DROP TABLE accounts;
   DROP TABLE p CASCADE;
!  DROP TABLE table_a, table_b;
  }
  =

  session "s1"
--- 21,36 ----
   CREATE TABLE table_b (id integer, value text);
   INSERT INTO table_a VALUES (1, 'tableAValue');
   INSERT INTO table_b VALUES (1, 'tableBValue');
+ =

+  CREATE TABLE jointest AS SELECT generate_series(1,10) AS id, 0 AS data;
+  CREATE INDEX ON jointest(id);
  }
  =

  teardown
  {
   DROP TABLE accounts;
   DROP TABLE p CASCADE;
!  DROP TABLE table_a, table_b, jointest;
  }
  =

  session "s1"
*************** step "updateforss"	{
*** 78,83 ****
--- 81,96 ----
  	UPDATE table_b SET value =3D 'newTableBValue' WHERE id =3D 1;
  }
  =

+ # these tests exercise mark/restore during EPQ recheck, cf bug #15032
+ =

+ step "selectjoinforupdate"	{
+ 	set enable_hashjoin to 0;
+ 	set enable_seqscan to 0;
+ 	explain (costs off)
+ 	select * from jointest a join jointest b on a.id=3Db.id for update;
+ 	select * from jointest a join jointest b on a.id=3Db.id for update;
+ }
+ =

  =

  session "s2"
  setup		{ BEGIN ISOLATION LEVEL READ COMMITTED; }
*************** step "readforss"	{
*** 104,109 ****
--- 117,123 ----
  	WHERE ta.id =3D 1 FOR UPDATE OF ta;
  }
  step "wrtwcte"	{ UPDATE table_a SET value =3D 'tableAValue2' WHERE id =3D=
 1; }
+ step "wrjt"	{ UPDATE jointest SET data =3D 42 WHERE id =3D 7; }
  step "c2"	{ COMMIT; }
  =

  session "s3"
*************** permutation "wx2" "partiallock" "c2" "c1
*** 135,137 ****
--- 149,152 ----
  permutation "wx2" "lockwithvalues" "c2" "c1" "read"
  permutation "updateforss" "readforss" "c1" "c2"
  permutation "wrtwcte" "readwcte" "c1" "c2"
+ permutation "wrjt" "selectjoinforupdate" "c2" "c1"

------- =_aaaaaaaaaa0--