fix: prevent batch infinite loop with arg length

[chrisyxlee]

Because the batch queries are only being closed when checking for 2 errors (batch results closed or no result), other errors cause the generated code to infinite loop. This changes from a for loop that only breaks on checking the errors to a for loop that also considers the the total number of params passed in.

Some errors will not infinite loop if you close the results yourself. However, there are other errors that you can't close --

• Context cancelled during a batch query
• Connection is busy
• Bad query

Bad queries typically happen in tests, but the infinite loop has eaten up >20Gb of RAM within a few minutes for me before.

This is usually what happens. It infinite loops, so I can't interrupt the process, and then I have to do ps aux | grep <> to find and kill the process manually:

Fixes #1678 (which was closed by the reporter since they found a workaround)

[chrisyxlee]

🤔 This is the test failure --
At first glance, it seems like the DB connection was overloaded, but not sure if it's a symptom of something that I need to fix.

--- FAIL: TestBatchBooks (0.02s)
    db_test.go:15: db: ***localhost:5432/postgres?sslmode=disable
    db_test.go:94: error updating book 2: conn busy
FAIL
FAIL	github.com/kyleconroy/sqlc/examples/batch/postgresql	0.029s

[kyleconroy]

Looking over the generated code, I think there's a cleaner way to implement the callbacks without having the check the return value of the error.

func (b *UpdateValuesBatchResults) Exec(f func(int, error)) {
	defer b.br.Close() // Close is safe to call multiple times
	for i := 0; i < b.tot; i++ {
		if b.closed {
			f(i, errrors.New("batch already closed"))
			continue
		}
		_, err := b.br.Exec()
		if f != nil {
			f(i, err)
		}
	}
}

func (b *UpdateValuesBatchResults) Close() error {
	return b.closed = true
	return b.br.Close()
}

Thoughts?

[chrisyxlee]

Oh yeah that's super clean, thanks! I'll circle back around and request another review after I've updated everything.

[chrisyxlee]

• I chose t for the index looping through the batch results. The i variable is already being used and is being specified here: https://github.com/kyleconroy/sqlc/blob/0a1b04eb47c80236db176805fe43f709042b805c/internal/codegen/golang/result.go#L242-L248
  Is there a way I can verify that this variable won't collide with other generated code?
• Added a lot more error checking for the user function f.
• I also noticed there was a defer rows.Close() within a loop, so I pulled that into an anonymous function to allow the deferral to happen ASAP.