postgresSQL Extended Query执行过程和sharding-proxy的处理-Toy模板网

这篇具有很好参考价值的文章主要介绍了postgresSQL Extended Query执行过程和sharding-proxy的处理。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

pg Extended Query

PostgreSQL: Documentation: 15: 55.2. Message Flow

多个阶段，可复用

Parse → DESCRIBE statement → SYNC
1. Parse 解析，将 sql 文本字符串，解析成 named preparedStatement 语句（生命周期随session）占位符和参数类型
2. Describe 获取元数据，返回 pst 参数描述符 parameterDescription 和结果集的行描述符 RowDescription
  由于此时还没执行 Bind，还未将语句传输到backend 执行，RowDescription中列的传输格式 codec format 还是0 ；参数的类型应该也只是根据客户端传到 frontend 指定的类型来的？
3. Sync 发完一串 extended messages 后需要发一个 sync 表示结束, 服务端一起处理；
  针对 sync 消息，服务端返回是否在事务中执行的状态 ‘T’ 在事务内， ‘I’ 不在事务内
BIND → DESCRIBE portal → EXECUTE → SYNC

a bind step, which creates a portal given a prepared statement and values for any needed parameters; and an execute step that runs a portal's query

bind 绑定阶段创建好一个可执行的 portal, 包括参数元数据、返回结果集的元数据（row 字段的pg类型 typeOid, 类型长度、传输方式 0-text, 1-binary 等) 参数值
DESCRIBE portal；此时是发到 backend 来获取元数据的，入参和查询结果的元数据才是真实的
execute 阶段执行并获取结果集，客户端可以根据上一步 describe portal 拿到的 rowDescription 中列的 format 来决定是用 0-text 还是 1-binary 要求服务端对参数和查询结果集中的字段值进行 format 后传输

同一个session里边，步骤一执行过后如果是 named portal ，后续就可以直接执行步骤二

步骤一执行完后, frontend session 缓存好命名 pst，下次同一个session再执行就能直接走步骤二就可以了

sharding-proxy 执行日志

步骤一

‘P’ Parse stmtcache_1 sql

‘D’ ‘S’ Describe preparedStatement

[DEBUG] 2023-04-07 17:16:53.166 [nioEventLoopGroup-3-3] o.a.s.db.protocol.codec.PacketCodec - Read from client a3f6d846 :
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 50 00 00 00 aa 73 74 6d 74 63 61 63 68 65 5f 31 |**P**....stmtcache_1|
|00000010| 00 53 45 4c 45 43 54 20 22 69 64 22 2c 22 73 74 |.SELECT "id","st|
|00000020| 75 64 65 6e 74 5f 6e 61 6d 65 22 20 46 52 4f 4d |udent_name" FROM|
|00000030| 20 22 74 5f 73 74 75 64 65 6e 74 5f 69 6e 66 6f | "t_student_info|
|00000040| 22 20 57 48 45 52 45 20 22 74 5f 73 74 75 64 65 |" WHERE "t_stude|
|00000050| 6e 74 5f 69 6e 66 6f 22 2e 22 69 64 22 20 3d 20 |nt_info"."id" = |
|00000060| 24 31 20 41 4e 44 20 22 74 5f 73 74 75 64 65 6e |$1 AND "t_studen|
|00000070| 74 5f 69 6e 66 6f 22 2e 22 69 64 22 20 3d 20 24 |t_info"."id" = $|
|00000080| 32 20 4f 52 44 45 52 20 42 59 20 22 74 5f 73 74 |2 ORDER BY "t_st|
|00000090| 75 64 65 6e 74 5f 69 6e 66 6f 22 2e 22 69 64 22 |udent_info"."id"|
|000000a0| 20 4c 49 4d 49 54 20 31 00 00 00 44 00 00 00 11 | LIMIT 1...**D**....|
|000000b0| 53 73 74 6d 74 63 61 63 68 65 5f 31 00 53 00 00 |**S**stmtcache_1.**S**..|
|000000c0| 00 04                                           |..              |
+--------+-------------------------------------------------+----------------+

请求报文解析成对应的 packet 对象 xxPacket，并创建对应的执行器 xxExecutor
postgresSQL Extended Query执行过程和sharding-proxy的处理

执行结果
postgresSQL Extended Query执行过程和sharding-proxy的处理
此时 rowDescription, dataFormat都是0

步骤二

‘B’ Bind

‘D’ + ‘P’ Describe porta

‘E’ Execute

‘S’ Sync

[DEBUG] 2023-04-07 17:16:53.304 [nioEventLoopGroup-3-3] o.a.s.db.protocol.codec.PacketCodec - Read from client a3f6d846 :
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 42 00 00 00 37 00 73 74 6d 74 63 61 63 68 65 5f |**B**...7.stmtcache_|
|00000010| 31 00 00 02 00 01 00 01 00 02 00 00 00 08 00 00 |1...............|
|00000020| 00 00 00 00 00 16 00 00 00 08 00 00 00 00 00 00 |................|
|00000030| 00 16 00 02 00 01 00 00 44 00 00 00 06 50 00 45 |........**D**....P.**E**|
|00000040| 00 00 00 09 00 00 00 00 00 53 00 00 00 04       |.........**S**....  |

报文解析，和对应执行器构建
postgresSQL Extended Query执行过程和sharding-proxy的处理