Re: Middleware Messages for FE/BE

From: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>
To: Hannu Krosing <hannuk(at)google(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>
Subject: Re: Middleware Messages for FE/BE
Date: 2021-08-20 12:58:59
Message-ID: 4dfa2b41-4678-7ec9-bea0-9114f8c0f7a9@redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Hannu,

On 8/19/21 3:52 PM, Hannu Krosing wrote:
> Jesper, please don't confuse my ramblings with Simon's initial proposal.
>
> As I understand, the original proposal was just about adding a new
> wire protocol message type, which then could be used for emitting
> custom messages by middleware support extension - likely loaded as a
> preloaded shared library - and consumed by some middleware, which
> could either be some proxy or connection pooler or something compiled
> as part of the libpq, JDBC or other client driver. So it was just
> about providing extensibility to the protocol (the same way almost
> everything else in PostgreSQL is extensible).
>

Yeah, but it is a change to the protocol which means that the client
drivers and middleware ecosystem needs to be updated to support that
message.

So, if the message was added to the protocol we could add another
message with the response to the request and make the protocol stricter, say

FE/M
Int32 - Length
Int16 - Request type (0 == Query capability, 1 == Execute capability)
Int32 - Capability type (0 == Failover, 1 == ..., ...)

BE/?
Int32 - Length
Int32 - Capability type
Byte - Support (0 == No, 1 == Yes)
Byten - Additional information

None of the client driver interfaces (specification API, like JDBC) has
functionality for this currently, so the client would need to type cast
the interface in all cases in order to get access to the trigger method, say

org.postgresql.jdbc.PgConnection.failover()

There could be custom capability type codes that targets specific
middleware like Simon suggested.

> But at least initially each middleware would process only it's own
> class, so a single if() and not a big switch/case :)
>

With a defined baseline of capabilities the client drivers and
middleware wouldn't have to invent their own codes.

> The things I talked about were some forward-looking proposals on how
> to use this capability and that some of the messages may at some point
> become used / usable by more than a single middleware component at
> which point they should be standardised .
>

It would be good to see a PoC of one capability implemented from the
client to the middleware that deals with coordination at the client level.

Best regards,
Jesper

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2021-08-20 13:28:40 Re: Push down time-related SQLValue functions to foreign server
Previous Message Justin Pryzby 2021-08-20 12:55:13 Re: Autovacuum on partitioned table (autoanalyze)