Re: pgoutput: schema cache cleanup after streamed 2PC - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: pgoutput: schema cache cleanup after streamed 2PC
Date
Msg-id CAD21AoC3+u4TwQ+BAjTYr=QdyQ-io1sByi-yHMkY-CJzdFPPxw@mail.gmail.com
Whole thread
In response to Re: pgoutput: schema cache cleanup after streamed 2PC  (Ayush Tiwari <ayushtiwari.slg01@gmail.com>)
Responses RE: pgoutput: schema cache cleanup after streamed 2PC
Re: pgoutput: schema cache cleanup after streamed 2PC
List pgsql-hackers
Hi,

On Thu, Sep 17, 2026 at 6:42 AM Ayush Tiwari
<ayushtiwari.slg01@gmail.com> wrote:
>
> Hi,
>
> On Thu, 17 Sept 2026 at 18:22, Hayato Kuroda (Fujitsu)
> <kuroda.hayato@fujitsu.com> wrote:
> > Thanks for the quick update. Let me dump my thought in [1] just in case.
> > Some tests may be needed (no need to include in core though).
>
> I used a separate publisher/subscriber test covering both commit and
> rollback. It confirmed that the cache usage stays flat with the cleanup,
> I too dont think this explicitly warrants a core test.
>
> > > I've moved cleanup_rel_sync_cache(txn->xid, true) to
> > > pgoutput_stream_prepare_txn() in v2 and updated the comments.
> >
> > I think the second argument should be renamed. Do you have anything in your mind?
> > My idea: mark_schema_sent.
>
> Thanks for the suggestion. I initially thought of set_schema_sent, but
> mark_schema_sent sounds better. I've used that in v3 and updated the nearby
> comments.
>
> > [1]:
> > IIUC pgoutput_commit_prepared_txn() and pgoutput_rollback_prepared_txn() are used
> > for both streamed and non-streamed cases. So putting the cleanup for streamed
> > transactions should be in pgoutput_stream_prepare_txn() as much as  possible.
> >
> > The main question here is whether we pass true or false for is_commit. I think
> > true can be used, because no need to re-send RELATION messages once it's handled
> > by the subscriber side.
> >
> > For streaming = on case, an apply worker firstly serialize streamed changes, then
> > it applies them when STREAM COMMIT or STREAM PREPARE are received. It means
> > RELATION messages have already handled in PREPARE phase.
> >
> > For streaming = parallel case, both leader and parallel apply worker handle
> > RELATION messages immediately.
>
> Thanks for the analysis.
>
> Attached v3 with changes.

Thank you for the report and making the patch!

I agree with the analysis and the fix. I've reviewed the v3 patch and
it looks good to me. IIUC this bug leads to not behavioral problems
but to memory leaks. I think we can push it without tests. I'm going
to push it (including back branches), barring any objections.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: pgsql: Revert online data checksum transitions
Next
From: Dean Rasheed
Date:
Subject: Re: Global temporary tables