From: Andres Freund <andres@anarazel.de>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16036: Segmentation fault while doing an update
Date: Fri, 4 Oct 2019 15:24:37 -0700
Message-ID: <20191004222437.45qmglpto43pd3jb@alap3.anarazel.de> (raw)
In-Reply-To: <20191004214300.pqe7fruaemklz5qn@alap3.anarazel.de>
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>
<746398E3-F4E1-4F14-A686-3394F27011DC@gmail.com>
<20191004032020.se46diwqas43e3tw@alap3.anarazel.de>
<11540.1570159561@sss.pgh.pa.us>
<20191004043021.ylfbxcjqyypphfft@alap3.anarazel.de>
<20191004192848.s3cgkt7n7g3cbvja@alap3.anarazel.de>
<20191004214300.pqe7fruaemklz5qn@alap3.anarazel.de>
Hi,
On 2019-10-04 14:43:00 -0700, Andres Freund wrote:
> > I think there's a good case to be made to backpatch the tests further
> > than 12, but I'm not sure about it? They do pass (with one error message
> > about a failure to delete changed to a failure to update, we didn't use
> > to be able to discern) back to 9.6, requiring
>
> I did push the tests back to 9.6.
There's a few ordering violations in the tests, e.g.:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2019-10-04%2021%3A51%3A13
key-a val-a-s1-ups1-ups1
step s1_c: COMMIT;
-s3: NOTICE: upd: text key-a = text key-a: t
-s3: NOTICE: upk: text val-a-s1-ups1-ups1 <> text mismatch: t
-s3: NOTICE: trigger: name rep_b_u; when: BEFORE; lev: ROWs; op: UPDATE; old: (key-a,val-a-s1-ups1-ups1) new: (key-a,val-a-s1-ups1-ups1-ups3)
-s3: NOTICE: trigger: name rep_a_u; when: AFTER; lev: ROWs; op: UPDATE; old: (key-a,val-a-s1-ups1-ups1) new: (key-a,val-a-s1-ups1-ups1-ups3)
-step s3_upd_a_data: <... completed>
+s2: NOTICE: upd: text key-a = text key-a: t
+s2: NOTICE: upk: text val-a-s1-ups1-ups1 <> text mismatch: t
+s2: NOTICE: trigger: name rep_b_u; when: BEFORE; lev: ROWs; op: UPDATE; old: (key-a,val-a-s1-ups1-ups1) new: (key-a,val-a-s1-ups1-ups1-upserts2)
+s2: NOTICE: trigger: name rep_a_u; when: AFTER; lev: ROWs; op: UPDATE; old: (key-a,val-a-s1-ups1-ups1) new: (key-a,val-a-s1-ups1-ups1-upserts2)
+step s2_upsert_a_data: <... completed>
key data
I was under the assumption that it'd be deterministic who gets to
continue with a speculative insertion, but that ain't so.
Peter, do you see an easy way around that? Do you consider that a
problem? ISTM we ought to make this fair, but that doing so would
require a bit bigger changes that we'd want to make in the backbranches?
Unless somebody comes up with an idea, I'll disable (or rewrite) the
"three way" tests involving two waiters for one insertion.
Regards,
Andres
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-bugs@postgresql.org
Cc: andres@anarazel.de, pg@bowt.ie, tgl@sss.pgh.pa.us, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16036: Segmentation fault while doing an update
In-Reply-To: <20191004222437.45qmglpto43pd3jb@alap3.anarazel.de>
* 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