Re: Decoding speculative insert with toast leaks memory

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Decoding speculative insert with toast leaks memory
Дата
Msg-id CAA4eK1KsLx6tZO_SiPVKZ3Zxd0TZy1U-Nzq6biAg6wcX7MCOJw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Decoding speculative insert with toast leaks memory  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Decoding speculative insert with toast leaks memory  (Dilip Kumar <dilipbalaut@gmail.com>)
Список 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
teston the back branches.
 
>

Sure, that makes sense.

-- 
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: contrib/pg_visibility fails regression under CLOBBER_CACHE_ALWAYS
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Strangeness with UNIQUE indexes and UTF-8