Re: [PATCH] Fall back to serializing when parallel apply runs out of DSM segments

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Baji Shaik <baji(dot)pgdev(at)gmail(dot)com>
Cc: Zhijie Hou <houzhijie22(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Fall back to serializing when parallel apply runs out of DSM segments
Date: 2026-11-11 17:45:48
Message-ID: CALj2ACXVbd7Cgc0YB7Ppb8F-72y9AGKOdc_Q3g7PrhcAcg=a4Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sun, Oct 25, 2026 at 8:24 AM Baji Shaik <baji(dot)pgdev(at)gmail(dot)com> wrote:
>
> I think both should be backpatched. 0001 to 16, where parallel apply
> was added, and 0002 to 14, since that code is the same on all supported
> branches. Thoughts?

I have a slightly different opinion here. I understand that a leader
erroring out while launching parallely apply workers has costs.
However, DSM running out of segments, IMO, is rare in practice and the
issue is not reported from the field. Even if it is hit in practice,
the recovery from that error is automatic for the apply worker starts
again and callers of make_new_segment() would hit OOM or similar error
anyway. I would just apply it for HEAD and be done with it.

Both the patches LGTM. Removing the comment change made in v1-0001 is
a nice thing, IMHO, comments describing what the code does in words
are better avoided.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2026-11-11 17:51:47 Re: A gap in preventing bogus parameterizations in a798660ebe3
Previous Message cca5507 2026-11-11 17:24:47 Re: Memoize: stale entry pointer after cache_store_tuple()