Re: Decoding speculative insert with toast leaks memory
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Petr Jelinek <petr.jelinek@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Tomas Vondra <tomas.vondra@enterprisedb.com>
Date: 2021-06-07T13:04:34Z
Lists: pgsql-hackers
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?
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 haven't yet checked on the back branches. Let's discuss if we think this patch looks fine then I can apply and test on the back branches.
>
Sure, that makes sense.
--
With Regards,
Amit Kapila.
Commits
-
Fix ABI break introduced by commit 4daa140a2f.
- e95f617acc48 11.13 landed
- 72b51e214a2c 12.8 landed
- 56e366f6757d 13.4 landed
-
Fix valgrind issue in pgoutput.c.
- 357cb8f07f95 13.4 landed
-
Fix decoding of speculative aborts.
- 43acadfcebec 9.6.23 landed
- 35f56c124a7a 10.18 landed
- 1f8a934e0a86 11.13 landed
- 40ad7ebff6ca 12.8 landed
- 602a32a685e4 13.4 landed
- 4daa140a2f50 14.0 landed
-
pgoutput: Fix memory leak due to RelationSyncEntry.map.
- d2505681211b 13.4 cited
-
Fix initialization of RelationSyncEntry for streaming transactions.
- 69bd60672af6 14.0 cited
-
Implement streaming mode in ReorderBuffer.
- 7259736a6e5b 14.0 cited