Re: Questions about logicalrep_worker_launch()

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Questions about logicalrep_worker_launch()
Date: 2025-05-01 04:57:11
Message-ID: [email protected]
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025/04/29 21:21, Amit Kapila wrote:
> On Mon, Apr 28, 2025 at 2:37 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>>
>> On 2025/04/26 3:03, Masahiko Sawada wrote:
>>> I agree with these changes.
>>>
>>> I think that while the changes for (2) should be for v19, the changes
>>> for (1) might be treated as a bug fix?
>>
>> Agreed. I've split the patch into two parts:
>>
>> 0001 is for (1) and is a bug fix that should be back-patched to v16,
>> where parallel apply workers were introduced. Since it didn't apply
>> cleanly to v16, I also created a separate patch specifically for v16.
>>
>
> The situation for parallel_apply workers is not as bad as for
> tablesync workers because even if the worker for parallel apply is not
> available, the apply worker will apply the changes by itself. OTOH, if
> the tablesync worker is not available, the tablesync will be pending
> till the time a worker for the same is not available. So, I am not
> sure if this is a clear cut bug which requires a fix in backbranches.

I'm fine with treating this as an improvement rather than a bug fix.
In any case, I've registered the patches for the next CommitFest.

The attached patches are the same as before, just rebased for the master branch.

>
> Additionally, shall we try to reproduce this case for parallel apply workers?

I noticed this issue while reading the code, so I haven't actually reproduced it.
Are you saying it's not possible to reproduce this in practice?

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

Attachment Content-Type Size
v3-0001-Fix-bug-that-could-block-the-startup-of-parallel-.patch text/plain 5.2 KB
v3-0002-Optimize-slot-reuse-after-garbage-collection-in-l.patch text/plain 1.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Junwang Zhao 2025-05-01 05:02:53 Re: Introduce some randomness to autovacuum
Previous Message Peter Geoghegan 2025-05-01 03:17:05 Re: Adding skip scan (including MDAM style range skip scan) to nbtree