Newer versions of cockroachdb aren’t open source anymore (being largely covered by a BSL license), but older versions were and could probably be forked if there were interest.
I helped debug the new pipeline mode (ability to run multiple statements at the same time) in libpq (official C client library) and this stuff is pretty complex. I wonder how many wire-compatible implementations from that table support this.
If I were to implement the postgres pipeline mode in a library of my own for the server side of the conversation, does libpq have any randomized client tests around this to get bugs to pop out that I could take advantage of?
There are some tests for this but I dont’t believe there is anything randomized. Another thing that you could use is tests from projects that use libpq in the pipeline mode. For example, in ODB (a C++ ORM) we have a bunch of “bulk operation” support tests which we run against Oracle, MSSQL, and now PG. So you could run those against your server implementation.
Thanks for the pointer to the bulk operation tests! One of the nice things about targeting such a common interface is the access to heavy-duty testing suites. Even though I have a pretty high amount of confidence in the randomization + fault injection approach that I’m taking in my tests for a DB I’m writing, it’s nice to throw as many things as I can at it for finding my blind spots.
One advantage of PostgreSQL wire compatibility is that there is no need for new drivers, but a different advantage is that proxies like Teleport, Envoy, and HAProxy can also work transparently with the compatible database.
Did HAproxy have specific support for postgresql? I thought it only had http and raw tcp connection load balancing, the latter of which is usable for many protocols.
Newer versions of cockroachdb aren’t open source anymore (being largely covered by a BSL license), but older versions were and could probably be forked if there were interest.
Thank you! I thought I was being liberal by saying “open” rather than “open source” but I changed the cockroach section to say “available”.
I helped debug the new pipeline mode (ability to run multiple statements at the same time) in
libpq
(official C client library) and this stuff is pretty complex. I wonder how many wire-compatible implementations from that table support this.If I were to implement the postgres pipeline mode in a library of my own for the server side of the conversation, does libpq have any randomized client tests around this to get bugs to pop out that I could take advantage of?
There are some tests for this but I dont’t believe there is anything randomized. Another thing that you could use is tests from projects that use
libpq
in the pipeline mode. For example, in ODB (a C++ ORM) we have a bunch of “bulk operation” support tests which we run against Oracle, MSSQL, and now PG. So you could run those against your server implementation.Thanks for the pointer to the bulk operation tests! One of the nice things about targeting such a common interface is the access to heavy-duty testing suites. Even though I have a pretty high amount of confidence in the randomization + fault injection approach that I’m taking in my tests for a DB I’m writing, it’s nice to throw as many things as I can at it for finding my blind spots.
One advantage of PostgreSQL wire compatibility is that there is no need for new drivers, but a different advantage is that proxies like Teleport, Envoy, and HAProxy can also work transparently with the compatible database.
Did HAproxy have specific support for postgresql? I thought it only had http and raw tcp connection load balancing, the latter of which is usable for many protocols.
I thought envoy was a transparent tcp proxy as well.
Pass, didn’t mention it because I have no idea. I know there are some protocol aware proxies like pgbouncer but IDK how many others.