From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Cc: alexk@hintbits.com
Subject: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Date: Fri, 14 Jun 2019 23:43:37 -0400
Message-ID: <20190615034337.GA24560@alvherre.pgsql> (raw)
In-Reply-To: <28491.1560526373@sss.pgh.pa.us>
On 2019-Jun-14, Tom Lane wrote:
> I wrote:
> >> Hm, I don't get that warning. Does this patch silence it, please?
>
> > Uh, no patch attached? But initializing the variable where it's
> > declared would certainly silence it.
>
> BTW, after looking around a bit I wonder if this complaint isn't
> exposing an actual logic bug. Shouldn't skip_tuple_lock have
> a lifetime similar to first_time?
I think there are worse problems here. I tried the attached isolation
spec. Note that the only difference in the two permutations is that s0
finishes earlier in one than the other; yet the first one works fine and
the second one hangs until killed by the 180s timeout. (s3 isn't
released for a reason I'm not sure I understand.)
I don't think I'm going to have time to investigate this deeply over the
weekend, so I think the safest course of action is to revert this for
next week's set.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
setup
{
drop table if exists tlu_job;
create table tlu_job (id integer primary key, name text);
insert into tlu_job values(1, 'a');
}
teardown
{
drop table tlu_job;
}
session "s0"
setup { begin; }
step "s0_forupdate" { select id from tlu_job where id = 1 for update; }
step "s0_commit" { commit; }
session "s1"
setup { begin; }
step "s1_keyshare" { select id from tlu_job where id = 1 for key share;}
step "s1_share" { select id from tlu_job where id = 1 for share; }
step "s1_update" { update tlu_job set name = 'b' where id = 1; }
step "s1_delete" { delete from tlu_job where id = 1; }
step "s1_rollback" { rollback; }
step "s1_commit" { commit; }
session "s2"
setup { begin; }
step "s2_for_update" { select id from tlu_job where id = 1 for update; }
step "s2_update" { update tlu_job set name = 'b' where id = 1; }
step "s2_delete" { delete from tlu_job where id = 1; }
step "s2_rollback" { rollback; }
step "s2_commit" { commit; }
session "s3"
setup { begin; }
step "s3_keyshare" { select id from tlu_job where id = 1 for key share; }
step "s3_share" { select id from tlu_job where id = 1 for share; }
step "s3_for_update" { select id from tlu_job where id = 1 for update; }
step "s3_update" { update tlu_job set name = 'c' where id = 1; }
step "s3_delete" { delete from tlu_job where id = 1; }
step "s3_rollback" { rollback; }
step "s3_commit" { commit; }
permutation "s0_forupdate" "s1_share" "s2_for_update" "s0_commit" "s3_share" "s3_for_update" "s1_rollback" "s3_rollback" "s2_rollback"
permutation "s0_forupdate" "s1_share" "s2_for_update" "s3_share" "s0_commit" "s3_for_update" "s1_rollback" "s3_rollback" "s2_rollback"
Attachments:
[text/plain] with_s0.spec (1.6K, ../20190615034337.GA24560@alvherre.pgsql/2-with_s0.spec)
download | inline:
setup
{
drop table if exists tlu_job;
create table tlu_job (id integer primary key, name text);
insert into tlu_job values(1, 'a');
}
teardown
{
drop table tlu_job;
}
session "s0"
setup { begin; }
step "s0_forupdate" { select id from tlu_job where id = 1 for update; }
step "s0_commit" { commit; }
session "s1"
setup { begin; }
step "s1_keyshare" { select id from tlu_job where id = 1 for key share;}
step "s1_share" { select id from tlu_job where id = 1 for share; }
step "s1_update" { update tlu_job set name = 'b' where id = 1; }
step "s1_delete" { delete from tlu_job where id = 1; }
step "s1_rollback" { rollback; }
step "s1_commit" { commit; }
session "s2"
setup { begin; }
step "s2_for_update" { select id from tlu_job where id = 1 for update; }
step "s2_update" { update tlu_job set name = 'b' where id = 1; }
step "s2_delete" { delete from tlu_job where id = 1; }
step "s2_rollback" { rollback; }
step "s2_commit" { commit; }
session "s3"
setup { begin; }
step "s3_keyshare" { select id from tlu_job where id = 1 for key share; }
step "s3_share" { select id from tlu_job where id = 1 for share; }
step "s3_for_update" { select id from tlu_job where id = 1 for update; }
step "s3_update" { update tlu_job set name = 'c' where id = 1; }
step "s3_delete" { delete from tlu_job where id = 1; }
step "s3_rollback" { rollback; }
step "s3_commit" { commit; }
permutation "s0_forupdate" "s1_share" "s2_for_update" "s0_commit" "s3_share" "s3_for_update" "s1_rollback" "s3_rollback" "s2_rollback"
permutation "s0_forupdate" "s1_share" "s2_for_update" "s3_share" "s0_commit" "s3_for_update" "s1_rollback" "s3_rollback" "s2_rollback"
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-committers@postgresql.org
Cc: alvherre@2ndquadrant.com, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org, alexk@hintbits.com
Subject: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
In-Reply-To: <20190615034337.GA24560@alvherre.pgsql>
* 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