When GBase 8a Parameters "Changed" But Queries Stayed the Same

Many "I already changed the parameter, why is the result still the old one?" situations in a gbase database aren't about the parameter failing to take effect — they're about not understanding the boundary: is it session‑level or system‑level? When exactly does it activate? Does the session need to reconnect or the cluster need to restart?

Three Parameter Classes by Activation Boundary

Class	Meaning	When It Takes Effect	Risk
Session‑level	Controls behavior within a single connection	Immediately for the current session	Old sessions reused by connection pools still carry old values
Online system‑level	Runtime global control that can be adjusted dynamically	New requests or new sessions only	Old and new sessions coexist with different settings
Requires restart/reload	Configuration‑file‑level runtime foundation	After restart or reload	Changing the file doesn't change the running state

Before diagnosing, ask three questions: which class does this parameter belong to? When should it theoretically activate? Was the SQL session that produced the problem freshly established?

Common Misjudgments

• Thinking a running session will automatically pick up a system‑level change.
• Assuming the client reconnected, when in fact the connection pool handed out the same old connection.
• Stopping after editing the config file without checking the runtime state.
• Assuming that because it worked in test, it will behave identically in production.
• Treating every parameter as suitable for online adjustment, leaving the change in a "half‑applied" state.

The common thread: focusing only on the action of changing the parameter, without verifying which layer the change actually reached.

A Typical Scenario

A DBA changes a parameter overnight. A freshly opened client in the test window shows the new behavior. The next morning, the scheduled batch job still produces old results. The first conclusion is usually "the parameter didn't take effect." But many scheduling systems and application layers reuse long‑lived connections to reduce overhead. Even though the parameter is active for new sessions, the old session is still running with the old value.

Verify what session you're in first:

SELECT user();
SELECT now();
SHOW VARIABLES;

If testing was done with a fresh client but the scheduler uses a persistent connection pool, the results should differ. Parameter validation must follow the actual execution path.

Why Test Passes but Production Behaves Differently

The root cause is rarely abstract "production complexity" — it's usually four concrete differences:

Aspect	Typical Test Practice	Production Reality	Result
Connection	New command‑line session	Scheduler reusing old connections	Different values visible
Timing	Query immediately after change	Batch job runs much later	State may have changed again
Sessions	Single client	Many concurrent sessions	Mixed old and new contexts
Scope	One statement	Long task chain	More points where parameter matters

A More Reliable Validation Approach

Step 1: Confirm runtime and config file match

SHOW VARIABLES;

Make sure you're looking at the current runtime value, not a stale config file entry.

Step 2: Validate with both an old and a new connection

If you only test with a new connection, the old‑connection path is invisible. A difference between the two tells you exactly where the boundary lies.

Step 3: Validate along the real call path

If production tasks run through a scheduler, application pool, or middleware, your verification should follow the same route. A successful manual direct connection doesn't guarantee the production path behaves the same.

Common Pitfalls

Pitfall	Symptom	Better Practice
Only edited the config file	SHOW still displays old value	Check runtime state as well
Only tested with a new connection	Scheduler still misbehaves	Verify with both old and new connections
Ignored connection pools	Manual test succeeds, system fails	Validate along the real call chain
No audit trail	Can't reconstruct what happened	Log timestamp, session, and result

Recommended Workflow

1. Determine which class the parameter belongs to.
2. Know when it theoretically activates.
3. Distinguish old sessions from new ones.
4. Validate along the actual production call path.

What truly matters isn't whether the parameter name "changed successfully" — it's whether the path that runs your business SQL actually sees the new value. This mindset isn't flashy, but it's the most reliable one in practice for a gbase database.