{"push_id":2848079901,"size":1,"distinct_size":1,"ref":"refs/heads/dist_stat_statements","head":"d3adb5df0b10de7b0263d38ae44b982c61052f75","before":"b985043b748ba3969a0f584c19ff63e59ab00031","commits":[{"sha":"d3adb5df0b10de7b0263d38ae44b982c61052f75","author":{"name":"Onder Kalaci","email":"bcbf1af39ab4ed4320d65078ead71095a76c08d1@citusdata.com"},"message":"Views to Provide some insight about the distributed transactions on Citus MX\n\nWith this commit, we implement two views that are very similar\nto pg_stat_activity, but showing queries that are involved in\ndistributed queries:\n\n    - citus_dist_stat_activity: Shows all the distributed queries\n    - citus_worker_stat_activity: Shows all the queries on the shards\n                                  that are initiated by distributed queries.\n\nBoth views have the same columns in the outputs. In very basic terms, both of the views\nare meant to provide some useful insights about the distributed\ntransactions within the cluster. As the names reveal, both views are similar to pg_stat_activity.\nAlso note that these views can be pretty useful on Citus MX clusters.\n\nNote that when the views are queried from the worker nodes, they'd not show the distributed\ntransactions that are initiated from the coordinator node. The reason is that the worker\nnodes do not know the host/port of the coordinator. Thus, it is advisable to query the\nviews from the coordinator.\n\nIf we bucket the columns that the views returns, we'd end up with the following:\n\n- Hostnames and ports:\n   - query_hostname, query_hostport: The node that the query is running\n   - master_query_host_name, master_query_host_port: The node in the cluster\n                                                   initiated the query.\n    Note that for citus_dist_stat_activity view, the query_hostname-query_hostport\n    is always the same with master_query_host_name-master_query_host_port. The\n    distinction is mostly relevant for citus_worker_stat_activity. For example,\n    on Citus MX, a users starts a transaction on Node-A, which starts worker\n    transactions on Node-B and Node-C. In that case, the query hostnames would be\n    Node-B and Node-C whereas the master_query_host_name would Node-A.\n\n- Distributed transaction related things:\n    This is mostly the process_id, distributed transactionId and distributed transaction\n    number.\n\n- pg_stat_activity columns:\n    These two views get all the columns from pg_stat_activity. We're basically joining\n    pg_stat_activity with get_all_active_transactions on process_id.\n\nSome open things for discussion:\n\n- [ ] We currently connect to the nodes with the CurrentUser() so that we get\n      the same privilage restrictions that pg_stat_activity provides. But, I\n      remember that one of the ideas was to connect with SuperUser(). The rationale\n      was that SuperUser's mostly have some reserved connection pools. So, in case of\n      an emergency situation where the admin wants to access to the transactions, the\n      admin would be able to connect. Do we need to take any action?\n\n- [ ] In order to get the local results, we could simply call the function. However, for ease\n      of implementation, I preferred to connect to the local node as well. Does it worth to\n      skip connections to the localhost?","distinct":true,"url":"https://api.github.com/repos/citusdata/citus/commits/d3adb5df0b10de7b0263d38ae44b982c61052f75"}]}
{"actor":{"display_login":"onderkalaci"}}