Thread

Re: Adding an extra byte to ReadyForQuery (B) to indicate HOLD cursors

Hannu Krosing <hannuk@google.com> — 2025-11-28T14:59:25Z

There are some differences in what kind of session-level objects ar e there.

For example pg_bouncer now supports prepared statements as these are
essentially "read-only" can be easily re-created without disturbing
their existing copies.

Temp tables, hold cursors and advisory locks are supposed to be unique
and also tied to a specific client.

Most GUCs are also supposed to be re-creatable and could be handled
like prepared statements, but one can have GUCs with side effects
which may fall in either category.


Having these things to keep in mind, the proper way forward could be
having a flag that enables "Rich ReadyForQuery" message which is more
than 5 bytes and could be then even be defined as something where you
specify the info you want in the flag and are expected to be able to
ignore any other info you are not interested in.

So to recap the proposal for Rich ReadyForQuery

A GUC which has a list of optionswe want the database to keep track of
and signal us in the ReadyForQuery nmessage

So for example when we set

SET backend_track_session_objects=cursors,temptables;

We would add the optional presence of both in the message [*]

ReadyForQuery (B)
    Byte1('Z')
        Identifies the message type. ReadyForQuery is sent whenever
the backend is ready for a new query cycle.
    Int32(7)
        Length of message contents in bytes, including self.
    Byte1
        Current backend transaction status indicator. Possible values
are 'I' if idle (not in a transaction block); 'T' if in a transaction
block; or 'E' if in a failed transaction block (queries will be
rejected until block is ended).
    Byte2
        'C' if hold cursors are active
    Byte3
        'T' if temp tables are active

The values after byte 1 should be unique across the options and
present only when there are requested session objects.


To extend this further we might also add a hook which can add its own values.


Maybe we can even integrate COMMIT LSN tracking here @Andres Freund ,
@Heikki Linnakangas

The LSN could have a representation like L followed by 8 bytes of
<uint64> LSN value. We do not want to add serialization here.


[*] https://www.postgresql.org/docs/current/protocol-message-formats.html#PROTOCOL-MESSAGE-FORMATS-READYFORQUERY








On Fri, Nov 28, 2025 at 2:45 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
>
>
> > On 28 Nov 2025, at 18:28, Kirill Reshke <reshkekirill@gmail.com> wrote:
> >
> > If we can inform the client that his postgresql backend has some
> > session-level objects (like prepared statement, temp table, advisory
> > lock or cursor), this will be very helpful.
>
> +1.
>
> Roman was starting discussion with very similar topic [0]. Not only drivers need this, proxies too.
>
>
> Best regards, Andrey Borodin.
>
> [0] https://www.postgresql.org/message-id/82741750755647@mail.yandex-team.ru