From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Reset the output buffer after sending from WalSndWriteData |
Date: | 2025-02-21 08:06:04 |
Message-ID: | b7c8d68f-5bda-4c33-adeb-ac3cef7c77ad@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/21/25 07:17, Masahiko Sawada wrote:
> On Thu, Feb 20, 2025 at 12:50 PM Markus Wanner
> <markus(dot)wanner(at)enterprisedb(dot)com> wrote:
>>
>> Hi,
>>
>> I recently stumbled over an issue with an unintentional re-transmission.
>> While this clearly was our fault in the output plugin code, I think the
>> walsender's exposed API could easily be hardened to prevent the bad
>> consequence from this mistake.
>>
>> Does anything speak against the attached one line patch?
>
> According to the documentation[1], OutputPluginPrepareWrite() has to
> be called before OutputPluginWrite().
Sure, that's exactly what we forgot. My complaint is that it's a mistake
that's unnecessarily hard to spot and the API could be improved. There
is no good reason to keep the sent data in the ctx->out buffer. But
clearly, there's some danger to it.
(Note that it wasn't quite as simple as you may think, though. With an
error involved in the send/recv loop of the walsender invoked from
OutputPluginWrite. The error handling code in PG_CATCH then attempting
to flush the queue with OutputPluginWrite.)
Arguably, one could even say that replacing the call to resetStringInfo
in WalSndPrepareWrite with an Assert(ctx->out->len == 0) would catch a
variant of improper use. And another Assert in WalSndWriteData to check
OutputPluginPrepareWrite had properly been invoked before can't hurt,
either.
Best Regards
Markus
Attachment | Content-Type | Size |
---|---|---|
0002-Add-asserts-to-guide-to-proper-API-usage.patch | text/x-patch | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2025-02-21 08:07:09 | Re: generic plans and "initial" pruning |
Previous Message | Peter Smith | 2025-02-21 07:25:52 | Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding |