Re: [PATCH] Fix ProcKill lock-group vs procLatch recycle race
| От | Evgeny Voropaev |
|---|---|
| Тема | Re: [PATCH] Fix ProcKill lock-group vs procLatch recycle race |
| Дата | |
| Msg-id | 552c2cba-2b5a-4a16-9e17-b9ea627b1b3b@tantorlabs.com обсуждение |
| Ответ на | [PATCH] Fix ProcKill lock-group vs procLatch recycle race (Vlad Lesin <vladlesin@gmail.com>) |
| Список | pgsql-hackers |
Hi Vlad, Concurrency problems are the most difficult to discover and reproduce. Thanks for that work! Since every patch is subject to testing, it is recommended to create a CommitFest card for it. Once in the CF-card, the patch set is picked up by CFBot and is thoroughly tested. You also will see whether the patch successfully applies to the target branch or not. You also might want to stick to a single PostgreSQL version in a thread, as all attached files are applied to the upstream during a CFBot job, which is impossible when a mail message includes patches for several PG versions simultaneously. Adhering to a single version per a thread and using a CommitFest card also make reviewers' task easier, for the reason that they can see the version and the base commit to which the patch should be applied. Patches for other PG's versions can probably be moved to separated threads. It is all by now. I am still looking into the code of the patch. I hope, later I can give some useful comments in regard to the solution itself. P.s. I tried to apply the patch to 3b28dad70e2. After 0002-ProcKill-PG18-core-lockgroup-freelist-race had been applied successfully, subsequent applying of 0003-PG18-unfixed-repro-tap-injection-harness failed. Best regards, Evgeny Voropaev, Tantor Labs, LLC.
В списке pgsql-hackers по дате отправления: