Re: Decoding speculative insert with toast leaks memory - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Decoding speculative insert with toast leaks memory
Date
Msg-id CAFiTN-ui+Vqf5ra7bj6npi5ToZV+D1MghTrnCVrXwEwGyO2n7w@mail.gmail.com
Whole thread Raw
In response to Re: Decoding speculative insert with toast leaks memory  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Decoding speculative insert with toast leaks memory  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
On Mon, Jun 7, 2021 at 6:34 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Mon, Jun 7, 2021 at 6:04 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> I have fixed all pending review comments and also added a test case which is working fine.
>

Few observations and questions on testcase:
1.
+step "s1_lock_s2" { SELECT pg_advisory_lock(2); }
+step "s1_lock_s3" { SELECT pg_advisory_lock(2); }
+step "s1_session" { SET spec.session = 1; }
+step "s1_begin" { BEGIN; }
+step "s1_insert_tbl1" { INSERT INTO tbl1 VALUES(1, repeat('a', 4000))
ON CONFLICT DO NOTHING; }
+step "s1_abort" { ROLLBACK; }
+step "s1_unlock_s2" { SELECT pg_advisory_unlock(2); }
+step "s1_unlock_s3" { SELECT pg_advisory_unlock(2); }

Here, s1_lock_s3 and s1_unlock_s3 uses 2 as identifier. Don't you need
to use 3 in that part of the test?

Yeah this should be 3.
 

2. In the test, there seems to be an assumption that we can unlock s2
and s3 one after another, and then both will start waiting on s-1 but
isn't it possible that before s2 start waiting on s1, s3 completes its
insertion and then s2 will never proceed for speculative insertion?

I agree, such race conditions are possible.  Currently, I am not able to think what we can do here, but I will think more on this.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Strangeness with UNIQUE indexes and UTF-8
Next
From: Robert Haas
Date:
Subject: Re: when the startup process doesn't