Re: BUG #19500: pgrepack logical decoding plugin can crash assert builds via SQL decoding API - Mailing list pgsql-bugs

From Alvaro Herrera
Subject Re: BUG #19500: pgrepack logical decoding plugin can crash assert builds via SQL decoding API
Date
Msg-id aicUE9JzOQCp1lLE@alvherre.pgsql
Whole thread
In response to RE: BUG #19500: pgrepack logical decoding plugin can crash assert builds via SQL decoding API  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Responses Re: BUG #19500: pgrepack logical decoding plugin can crash assert builds via SQL decoding API
List pgsql-bugs
On 2026-Jun-05, Zhijie Hou (Fujitsu) wrote:

> I have no objection to the proposed approach. But I would like to confirm
> whether reporting an ERROR in the startup callback (when the context is not a
> REPACK decoding worker) is considered acceptable.
> 
> Like:
> 
> repack_startup(LogicalDecodingContext *ctx, OutputPluginOptions *opt,
>                bool is_init)
> ...
>     if (!AmRepackWorker())
>         ereport(ERROR,
>                 errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>                 errmsg("this plugin can only be used by REPACK (CONCURRENTLY)"));

Hmm, yeah, that works for me, we can ditch the magic number then.  I'm
considering something like the attached.  I added the test case and
edited nearby comments.  Will stare some more at it tomorrow ...

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/

Attachment

pgsql-bugs by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: BUG #19491: Segmentation fault triggered by IS NULL
Next
From: Ashutosh Sharma
Date:
Subject: Re: BUG #19508: pg_buffercache_pages() crashes the backend with an incompatible caller-supplied record definition