Skip to content

Bump Go from 1.24 to 1.25#99

Open
tuhaihe wants to merge 10 commits into
apache:mainfrom
tuhaihe:upgrade-go-1.25
Open

Bump Go from 1.24 to 1.25#99
tuhaihe wants to merge 10 commits into
apache:mainfrom
tuhaihe:upgrade-go-1.25

Conversation

@tuhaihe

@tuhaihe tuhaihe commented May 15, 2026

Copy link
Copy Markdown
Member

closes: #ISSUE_Number


Change logs

Describe your change clearly, including what problem is being solved or what document is being added or updated.

Contributor's checklist

Here are some reminders before you submit your pull request:

Comment thread go.mod Outdated
woblerr added 4 commits June 26, 2026 00:02
The test held locks with raw BEGIN/COMMIT SQL on DBConn and then reused the
same connection for polling. With pgx v5 this can release the raw transaction
lock, so gpbackup was not blocked and the test observed 0 deadlock traps.

Use explicit DBConn transactions, separate polling connections, wait for
goroutines before closing connections, and wait for the expected 2 blocked
AccessExclusiveLock requests.
After moving to pgx v5, database errors are returned as
pgx/v5/pgconn.PgError. The old jackc/pgconn type assertions no longer
matched, so backup lock handling could treat unexpected errors as
lock-not-available, and restore COPY errors could lose their CONTEXT.

Use errors.As with pgx/v5 pgconn in backup and restore code, update the
restore test, and remove the old pgconn dependency.
The deadlock and signal handler e2e tests still held locks with raw BEGIN/COMMIT SQL on DBConn and reused those connections for pg_locks polling.
With pgx v5 this can release the raw transaction lock or leave goroutines polling on closed connections, causing missing blocked-lock counts and DBConn.Get panics.
Use explicit transactions, dedicated lock and polling connections, and synchronize goroutines before closing test connections.
The test intended to verify that gpbackup does not keep a lock on
pg_catalog.gp_segment_configuration after passing that metadata query and
blocking later on pg_catalog.pg_trigger. However, the old test did not actually
exercise that state: it used raw BEGIN/COMMIT SQL through DBConn, committed before gpbackup was started, queried pg_locks in an unsynchronized goroutine, and ignored query errors while scanning SELECT * into an int.

Use an explicit DBConn transaction on a dedicated lock connection, start
gpbackup while the pg_trigger lock is still held, wait until gpbackup is visibly
blocked on pg_trigger, and then synchronously assert that no
gp_segment_configuration locks remain. Finally release pg_trigger and verify
gpbackup completes successfully.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants