I'm fairly sure that the query snapshot is established at Bind time, which means that this SELECT will run with a snapshot that indeed does not see the effects of the UPDATE.
To my mind there is not a lot of value in performing Bind until you are ready to do Execute. The only reason the operations are separated in the protocol is so that you can do multiple Executes with a row limit on each one, to retrieve a large query result in chunks.
So you would suggest changing my message chain to send Bind right after Execute, right? This would yield the following messages:
P1/P2/D1/B1/E1/D2/B2/E2/S (rather than the current P1/D1/B1/P2/D2/B2/E1/C1/E2/C2/S)
This would mean that I would switch to using named statements and the unnamed portal, rather than the current unnamed statement
and named portals. If I recall correctly, I was under the impression that there are some PostgreSQL performance benefits to using the
unnamed statement over named statements, although I admit I can't find any documentation backing that. Can you confirm that the two