Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BackendKeyData shouldn't be a required message during startup #84

Closed
jordanlewis opened this issue Jan 27, 2017 · 3 comments
Closed

BackendKeyData shouldn't be a required message during startup #84

jordanlewis opened this issue Jan 27, 2017 · 3 comments

Comments

@jordanlewis
Copy link

The py-postgresql library requires that a BackendKeyData or 'K' message be sent during connection initialization from Postgres, which leads to failure to connect to servers speaking the Postgres wire format that don't send such a message.

This message is not strictly required by the Postgres message flow rules, so this library should be able to tolerate not receiving such a message.

@jwp
Copy link
Contributor

jwp commented Feb 6, 2017

The message flow rules on that page are of questionable normative quality. That is, I'm not sure your interpretation is consistent with: "but in the normal case the backend will send some ParameterStatus messages, BackendKeyData, and finally ReadyForQuery." found in that page. However, if libpq is handling the absence of BackendKeyData without error, your interpretation may effectively be correct.

In any case, if you're seeking complete transparency, your server will need to send BackendKeyData in order to allow applications to perform query interrupts.

@jwp
Copy link
Contributor

jwp commented Dec 28, 2020

Finally got around to analyzing this further: https://github.com/postgres/postgres/blob/REL_13_1/src/interfaces/libpq/fe-protocol3.c#L265

It looks like libpq's treatment of BackendKeyData as optional might be an artifact of its implementation. Whether this behavior is intentional still seems ambiguous to me. There is no explicit branch during negotiation that allows us to clearly recognize that the message is intended to be optional. (Also, libpq's ability to eat subsequent 'K' messages looks suspicious to my eyes.)

Given that the canonical PQ server implementation unconditionally sends BackendKeyData, it seems reasonable that a client implementation might make the choice of expecting it unconditionally.

It is advisable to mimic the server's behavior in order to avoid possible incompatibilities with other implementations as well as the incompatibility with this driver.

I'm not closing this out as a statement that I'm unwilling to toss a branch in the negotiation code. I'm quite willing to, but I would like to see more evidence that it is intended to be optional as not sending BackendKeyData is a deviation from the behavior of the server.

@jwp jwp closed this as completed Dec 28, 2020
@jordanlewis
Copy link
Author

Fair enough. Thanks @jwp! cc @rafiss

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants