Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Persistent queries can be returned to two callers #73

Open
andrew-d opened this issue Jun 7, 2023 · 0 comments
Open

Persistent queries can be returned to two callers #73

andrew-d opened this issue Jun 7, 2023 · 0 comments

Comments

@andrew-d
Copy link
Member

andrew-d commented Jun 7, 2023

This code doesn't check whether we've already returned the *stmt to a caller, so it's possible that calling conn.PrepareContext twice in a row can return the same *stmt to two different callers:
https://github.com/tailscale/sqlite/blob/main/sqlite.go#L193-L196

This means that e.g. running a query from each of the two not-actually-different stmts, getting rows1 and rows2, and then calling rows1.Next will also step rows2.
andrew-d added a commit that referenced this issue Jun 7, 2023
@andrew-d
sqlite: don't return persistent queries to two callers
b433152 
This test case used to fail with:

    === RUN   TestPrepareReuse
        sqlite_test.go:1129: rows2: num=2, want 1
    --- FAIL: TestPrepareReuse (0.00s)

This indicates that we were erroneously returning the same "persisted"
query twice, which resulted in the two sets of Rows returned affecting
each other. Instead, only persist queries in c.stmts on Close, after
they've been reset and are ready for re-use.

Updates #73

Signed-off-by: Andrew Dunham <andrew@du.nham.ca>
@andrew-d andrew-d mentioned this issue Jun 7, 2023
Merged
andrew-d added a commit that referenced this issue Jun 7, 2023
@andrew-d
sqlite: don't return persistent queries to two callers
d904a38 
This test case used to fail with:

    === RUN   TestPrepareReuse
        sqlite_test.go:1129: rows2: num=2, want 1
    --- FAIL: TestPrepareReuse (0.00s)

This indicates that we were erroneously returning the same "persisted"
query twice, which resulted in the two sets of Rows returned affecting
each other. Instead, only persist queries in c.stmts on Close, after
they've been reset and are ready for re-use.

Updates #73

Signed-off-by: Andrew Dunham <andrew@du.nham.ca>
andrew-d added a commit that referenced this issue Jun 7, 2023
@andrew-d
sqlite: don't return persistent queries to two callers
28cb89b 
This test case used to fail with:

    === RUN   TestPrepareReuse
        sqlite_test.go:1129: rows2: num=2, want 1
    --- FAIL: TestPrepareReuse (0.00s)

This indicates that we were erroneously returning the same "persisted"
query twice, which resulted in the two sets of Rows returned affecting
each other. Instead, only persist queries in c.stmts on Close, after
they've been reset and are ready for re-use.

Updates #73

Signed-off-by: Andrew Dunham <andrew@du.nham.ca>
andrew-d added a commit that referenced this issue Jun 8, 2023
@andrew-d
sqlite: don't return persistent queries to two callers
ed5a0ba 
This test case used to fail with:

    === RUN   TestPrepareReuse
        sqlite_test.go:1129: rows2: num=2, want 1
    --- FAIL: TestPrepareReuse (0.00s)

This indicates that we were erroneously returning the same "persisted"
query twice, which resulted in the two sets of Rows returned affecting
each other. Instead, only persist queries in c.stmts on Close, after
they've been reset and are ready for re-use.

Updates #73

Signed-off-by: Andrew Dunham <andrew@du.nham.ca>
andrew-d added a commit that referenced this issue Jun 8, 2023
@andrew-d
sqlite: don't return persistent queries to two callers
c40e971 
This test case used to fail with:

    === RUN   TestPrepareReuse
        sqlite_test.go:1129: rows2: num=2, want 1
    --- FAIL: TestPrepareReuse (0.00s)

This indicates that we were erroneously returning the same "persisted"
query twice, which resulted in the two sets of Rows returned affecting
each other. Instead, only persist queries in c.stmts on Close, after
they've been reset and are ready for re-use.

Updates #73

Signed-off-by: Andrew Dunham <andrew@du.nham.ca>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@andrew-d