pgwire: create a framework for pre-serve connection logic

[knz]

Parent PRs:

• server: enabling instantiating secondary tenant servers in-memory  #84608
• server,netutil: clean up the connManager logic #91739
• server: use a shared HTTP listener for all in-memory tenant servers #91744
• pgwire: unexport ServerMetrics, rename to tenantSpecificMetrics #92574

Epic: CRDB-14537

[cockroach-teamcity]

This change is 

[rafiss]

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @knz)

---

-- commits line 15 at r2:
just a question: why is it named sql.pre_serve... and not sql.pre_auth...? i feel that from a client's perspective, the connection is already being "served" once it reaches the business logic inside of CRDB. they shouldn't need to care about the various server objects we have in our code.

also, will this make it harder for serverless users to see where their credits are being used in the case of high authentication load? or do these pre_serve bytes no longer count against them? (if so, that would be worth making explicit in the release notes)

---

pkg/sql/pgwire/pre_serve.go line 55 at r2 (raw file):

type PreServeConnHandler struct {
	errWriter errWriter
	cfg       struct {

why do we need this empty cfg? explain with a comment? (and maybe don't put the } on a new line)

---

pkg/sql/pgwire/pre_serve.go line 106 at r2 (raw file):

) (err error) {
	defer func() {
		if err != nil {

when would err ever be non-nil?

---

pkg/sql/pgwire/server.go line 1402 at r2 (raw file):

// sequence. Later error sends during/after authentication are handled
// in conn.go.
func (s *Server) sendErr(ctx context.Context, conn net.Conn, err error) error {

perhaps the function's job would be more clear if it was renamed sendPreAuthErr or sendPreServeErr?

[knz]

why is it named sql.pre_serve... and not sql.pre_auth...?

• why not pre_auth: because there is more remaining tenant-specific logic pre-authentication. The split we're designing is not about pre-auth vs post-auth; it's pre-tenant-assignment vs post-tenant-assignment, with some remaining pre-auth work to do after tenant assignment.

• why pre_serve: because i'm extracting the work done before ServeConn is called. (it's pre-ServeConn really, hence PreServeConnHandler)

[knz]

will this make it harder for serverless users to see where their credits are being used in the case of high authentication load?

I don't see it - as you'll see in the PR chain, the amount of pre-serve work is minimal.

[abarganier]

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @knz)

---

pkg/sql/pgwire/pre_serve.go line 75 at r5 (raw file):

// tenantIndependentMetrics is the set of metrics for the
// pre-serve part of connection handling, before the connection
// is routed to a specific tenant.

nit: until tsdb supports tenant cardinality (or maybe I missed it... has this been implemented?) can we specify the semantics of "tenant independent metrics"? Are they stored with tenant-level cardinality, or just available in _status/vars / in-memory?

Code quote:

// tenantIndependentMetrics is the set of metrics for the
// pre-serve part of connection handling, before the connection
// is routed to a specific tenant.

[knz]

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @abarganier, @knz, and @rafiss)

---

-- commits line 15 at r2:

Previously, rafiss (Rafi Shamim) wrote…

just a question: why is it named sql.pre_serve... and not sql.pre_auth...? i feel that from a client's perspective, the connection is already being "served" once it reaches the business logic inside of CRDB. they shouldn't need to care about the various server objects we have in our code.

also, will this make it harder for serverless users to see where their credits are being used in the case of high authentication load? or do these pre_serve bytes no longer count against them? (if so, that would be worth making explicit in the release notes)

• why not pre_auth: because there is more remaining tenant-specific logic pre-authentication. The split we're designing is not about pre-auth vs post-auth; it's pre-tenant-assignment vs post-tenant-assignment, with some remaining pre-auth work to do after tenant assignment.

• why pre_serve: because i'm extracting the work done before ServeConn is called. (it's pre-ServeConn really, hence PreServeConnHandler)

---

pkg/sql/pgwire/pre_serve.go line 55 at r2 (raw file):

Previously, rafiss (Rafi Shamim) wrote…

why do we need this empty cfg? explain with a comment? (and maybe don't put the } on a new line)

We don't need it. it was dead code. removed.

---

pkg/sql/pgwire/pre_serve.go line 106 at r2 (raw file):

Previously, rafiss (Rafi Shamim) wrote…

when would err ever be non-nil?

This is just a skeleton for the PreServe function that gets populated further in #92577. At that point, err can become non-nil.

---

pkg/sql/pgwire/pre_serve.go line 75 at r5 (raw file):

Previously, abarganier (Alex Barganier) wrote…

nit: until tsdb supports tenant cardinality (or maybe I missed it... has this been implemented?) can we specify the semantics of "tenant independent metrics"? Are they stored with tenant-level cardinality, or just available in _status/vars / in-memory?

They are tenant-independent so by definition they are not tenant-level. They are just regular metrics and stored alongside the others. What type of specification do you have in mind?

---

pkg/sql/pgwire/server.go line 1402 at r2 (raw file):

Previously, rafiss (Rafi Shamim) wrote…

perhaps the function's job would be more clear if it was renamed sendPreAuthErr or sendPreServeErr?

I guess that's reasonable. Done.