SQL: show local node processlist

[a6802739]

@knz, This PR was used to show local node processlist, see #7003. And I just refer to you PR #10317.

[cockroach-teamcity]

This change is 

[knz]

Thanks for taking #10317 over. However, the points raised in there still hold: the current code is subject to a race condition, when queries to the new crdb_internal read the state of the session concurrently with execution. The race condition makes the values in crdb_internal potentially unsound, and will cause our race detection tests to complain.

The proper approach, suggested earlier by Andrei, is to make a copy of the useful Session fields after each statement or each transaction, and only read from that copy in the code that populates the virtual table. The copy would be protected by a mutex.

[a6802739]

@knz , You mean we should lock the field of session when we use them to create table crdb_internal.sessions?

[knz]

Locking the fields used in Session directly is a non-starter: there are so many uses of these fields that 1) it would be very hard to guarantee they are locked everywhere then 2) the performance overhead would be terrible.

The proper approach is to copy all the fields in Session that are useful to the process list in between the execution of two statements. Then the copy would be dedicated to the process list generator. The copy needs to be locked because it can be accessed concurrently both by the process list generator and in-between executes. Also, care must be taken to do this properly when parallel statement execution is also enabled, because then the idea of "in between execution" is not well-defined any more.

[a6802739]

@knz , you mean like this? when we create table crdb_internal.sessions

            s.Lock()
            queryInfo := QueryInfo{
                Database : s.Database,
                User : s.User,
                ...
            }
            s.Unlock()

[a6802739]

@knz, Oh, I see. You mean when we begin execute a statement in the session, we should make a copy of the field of this session, and then when we create table crdb_internal.sessions, we could just use this copy as the process list generator?

So we should add a QueryInfo field in struct Session, And When we execute the statement, we could copy some field of session into QueryInfo.

[knz]

Yes, that is the basic idea.

However there is some additional complexity because there may be multiple statements executing in parallel in the session.

[a6802739]

@knz, hou could multiple statements executing in parallel in the session this happen?

[knz]

See https://github.com/cockroachdb/cockroach/blob/master/docs/RFCS/sql_parallelization.md
and #14188.

[a6802739]

@knz, I just add the statement when we execute the statement in execStmt( and execStmtInParallel(.

[a6802739]

@knz, could you help me a review. Thank you very much.

[tamird]

@a6802739 how does this relate to #16072 ? If it's still relevant, could you rebase it?

cc @knz @itsbilal

[knz]

Dear songhao, we have implemented this feature already in a different way, using the new statements SHOW JOBS and SHOW QUERIES. Soon we will also implement PAUSE/CANCEL for them.
I believe this PR can be closed. If you wish us to enhance this feature in any way, please let us know.