From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: protocol-level wait-for-LSN |
Date: | 2024-10-30 09:04:41 |
Message-ID: | CAGECzQQWkWGWdMvWnAWqL=VKLsLt79Qq42i1fkYc4VQCpfBARg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 28 Oct 2024 at 17:58, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> > - The Query message sends an LSN to wait for. (This doesn't handle the
> > extended query protocol yet.)
>
> I'd suggest adding a new message type for this, so that it works the
> same with simple and extended query. Or if you just want to wait without
> issuing any query.
Big +1 to this. After thinking about it more, I think this would make
a fancy pooler much easier to implement. Because then the pooler could
simply send such a new WaitForLSN message whenever it wants to, e.g.
before handing off the server connection to the client. Instead of
having to intercept every Query/Execute message that the client is
sending, and modify that in place before sending it on to the server.
Writing the previous down made me realize that using a separate
message would be nice for this usecase too. As opposed to including it
in ReadyForQuery. Because if the fancy pooler wants to configure these
LSNs transparently for a client that has not set the protocol
parameter, it would need to strip the new LSN field from the
ReadyForQuery message before forwarding it to the client. Stripping
out a whole message is generally easier to do than modifying messages
in place.
From | Date | Subject | |
---|---|---|---|
Next Message | Kirill Reshke | 2024-10-30 09:07:41 | Re: Useless field ispartitioned in CreateStmtContext |
Previous Message | Jelte Fennema-Nio | 2024-10-30 09:03:27 | Re: protocol-level wait-for-LSN |