From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Dave Cramer <davecramer(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: More protocol.h replacements this time into walsender.c |
Date: | 2025-08-04 21:23:55 |
Message-ID: | aJEk695hVaEc4ve3@nathan |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 04, 2025 at 02:11:26PM -0700, Jacob Champion wrote:
> On Mon, Aug 4, 2025 at 12:56 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>> The replication protocol uses many of the
>> existing PqMsg macros already, so it would be a little strange if only a
>> subset of the replication protocol messages used the special prefix.
>
> May I ask why? These messages are legitimately different; they're
> tunneled through CopyData, so their reservations don't collide with
> the top-level codes.
Ah, I missed that finer detail. IIUC the codes at hands are _only_ used in
these tunneled messages, in which case they belong to a distinct category.
>> There's also backups, which use the replication protocol but
>> have their own special characters [0]. If we're going the prefix route,
>> would we add another prefix for those, or use the replication one?
>
> My vote would be to add another. 'p' is a password message in the
> top-level protocol (one of many, actually), a progress message in a
> backup stream, and a status request in a replication stream, so I
> think they deserve their own namespaces.
These also seem to use the same tunneling mechanism. I retract my
objection.
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Naga Appani | 2025-08-04 21:51:30 | Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring |
Previous Message | Jacob Champion | 2025-08-04 21:11:26 | Re: More protocol.h replacements this time into walsender.c |