| From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
|---|---|
| To: | n(dot)kalinin(at)postgrespro(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19500: pgrepack logical decoding plugin can crash assert builds via SQL decoding API |
| Date: | 2026-05-29 14:23:35 |
| Message-ID: | add10bd7-d351-4630-858b-b9b77144f0a9@app.fastmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
On 2026-05-28, PG Bug reporting form wrote:
> It appears that the pgrepack output plugin is accessible through the SQL
> logical decoding API, even though the plugin code explicitly indicates that
> this interface is not supported. Reading changes from such a slot can cause
> a backend process crash in builds with asserts enabled.
> Is this considered normal behavior for the pgrepack plugin, i.e. essentially
> a “don’t do that” situation?
Yeah, I would like to have a way to prevent this, if only for user-friendliness, but it's not terribly pressing since only a role with REPLICATION privs can create the replication slot, which as I recall are already pretty powerful.
--
Álvaro Herrera
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2026-05-29 15:35:05 | BUG #19501: btree_gist: use float4/float8 comparison functions to handle NaN correctly |
| Previous Message | Michael Paquier | 2026-05-29 05:00:20 | Re: BUG #19494: Error on transaction commit inside pipeline triggers psql's Assert |