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-28 17:07:57 |
Message-ID: | CAGECzQTNhLzOiUcDNrUCwYxn6mQVbriCXVZBBMHXbqzNhn+VwA@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.
I imagine a libpq interface like this.
lsn = PQcurrentLSN(primaryConn)
PQsendWaitLSN(secondaryConn, lsn)
PQsendQuery(secondaryConn, ...)
One thing I'm wondering is if the current lsn could be a read-only GUC
that is reported through ParameterStatus. Because a downside of making
it part of ReadyForQuery is that you only get a ReadyForQuery at the
end of a pipeline, while a pipeline can contain multiple commits if
you use explicit BEGIN/COMMIT in your pipeline. It might be nice to be
able to wait on those commits before you've received ReadyForQuery. On
the other hand, that seems like a rather exotic usecase that maybe is
not worth thinking about too much.
From | Date | Subject | |
---|---|---|---|
Next Message | Marcos Pegoraro | 2024-10-28 17:29:44 | Re: Should we support casting between ARRAYs and JSON(B)? |
Previous Message | Aleksander Alekseev | 2024-10-28 17:06:01 | Should we support casting between ARRAYs and JSON(B)? |