Skip to content
Tutorialintermediate · 2 min read · 2026-11-01

pgAdmin 4 v9.19 Upgrade Checklist

A practical checklist for upgrading pgAdmin 4 to v9.19: verify the installed app version, plan a safe rollout, prioritize the security fixes, and test the new extended statistics and editable-view improvements on sample SQL objects.

Why this release needs attention

pgAdmin 4 v9.19 is not just a feature release. The PostgreSQL news announcement says it includes 136 bug fixes and new features, including fixes for 15 security vulnerabilities covering CVE-2026-116238 through CVE-2026-116252.

Treat this as a planned but high-priority upgrade: do not update blindly on a production admin workstation or shared pgAdmin server, but do not postpone it like a cosmetic UI update either.

Upgrade checklist before touching production

Start by verifying the pgAdmin application version, not the PostgreSQL server version. A common mistake is running SELECT version(); and assuming it tells you the pgAdmin version; it only reports the database server.

Use this checklist: - Record the currently installed pgAdmin version from the app UI or package manager. - Identify how pgAdmin was installed: desktop package, container, Python package, or OS repository. - Export or otherwise back up saved connection metadata and any team-specific configuration before replacing the app. - Test the upgrade first against a non-production PostgreSQL server. - After upgrading, verify login, saved server connections, query tool execution, object browser navigation, and View/Edit Data behavior.

Test the new Statistics node with extended statistics

One notable v9.19 feature is a Statistics node for creating and managing extended statistics. In PostgreSQL, extended statistics help the planner estimate queries better when columns are correlated or when combinations of columns matter more than each column independently.

After upgrading pgAdmin, create a small test table, add extended statistics, run ANALYZE, and confirm that pgAdmin shows the statistics object under the relevant table. This is a good smoke test because it exercises both SQL object creation and pgAdmin object-tree refresh behavior.

Test editing through simple auto-updatable views

Another notable v9.19 improvement is that data can be edited through simple auto-updatable views in View/Edit Data. The word simple matters: views that are joins, aggregates, grouping queries, or computed projections may not be automatically editable.

For a safe test, use a view over one base table with direct columns. Add WITH LOCAL CHECK OPTION if you want PostgreSQL to reject edits that would make a row disappear from the view predicate.

Runnable model: editing a view updates base data

The runnable example below uses SQLite because this lesson sandbox runs SQLite, not PostgreSQL. SQLite views are not automatically updatable, so the example uses an INSTEAD OF UPDATE trigger to model the same underlying idea: editing rows exposed by a view must be translated into changes on the base table.

In PostgreSQL, simple views can be auto-updatable without such a trigger. In pgAdmin v9.19, the improvement is about using View/Edit Data with those simple auto-updatable views.

Code

SQL (SQLite) · SQLite model of editing rows exposed by a view✓ Executed & verified · 3.40.1 2022-12-28 14:03:47 df5c253c0b3dd24916e4ec7cf77d3db5294cc9fd45ae7b9c5e82ad8197f3alt1
CREATE TABLE tasks (
  id INTEGER PRIMARY KEY,
  title TEXT NOT NULL,
  status TEXT NOT NULL,
  archived INTEGER NOT NULL DEFAULT 0
);

INSERT INTO tasks (id, title, status, archived) VALUES
  (1, 'renew cert', 'todo', 0),
  (2, 'backup db', 'todo', 0),
  (3, 'old migration', 'done', 1);

CREATE VIEW active_tasks AS
SELECT id, title, status
FROM tasks
WHERE archived = 0;

CREATE TRIGGER active_tasks_update
INSTEAD OF UPDATE ON active_tasks
BEGIN
  UPDATE tasks
  SET title = NEW.title,
      status = NEW.status
  WHERE id = OLD.id
    AND archived = 0;
END;

UPDATE active_tasks
SET status = 'done'
WHERE id = 1;

SELECT id || ':' || title || ':' || status
FROM active_tasks
ORDER BY id;

This SQLite script demonstrates the core idea behind editable views: the user edits the view, but the base table is what actually changes. SQLite needs an INSTEAD OF trigger; PostgreSQL simple views can be auto-updatable.

SQL (SQLite) · PostgreSQL sample: create extended statisticsIllustrative · not executed
DROP TABLE IF EXISTS cb_orders;

CREATE TABLE cb_orders (
  id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  customer_id integer NOT NULL,
  city text NOT NULL,
  status text NOT NULL
);

INSERT INTO cb_orders (customer_id, city, status) VALUES
  (1, 'Pune', 'OPEN'),
  (1, 'Pune', 'OPEN'),
  (2, 'Delhi', 'CLOSED'),
  (2, 'Delhi', 'CLOSED'),
  (3, 'Bengaluru', 'OPEN');

CREATE STATISTICS cb_orders_customer_status_stats
  (dependencies, ndistinct)
ON customer_id, status
FROM cb_orders;

ANALYZE cb_orders;

SELECT statistics_name
FROM pg_stats_ext
WHERE schemaname = 'public'
  AND tablename = 'cb_orders';

Run this on PostgreSQL, then refresh the table in pgAdmin v9.19 and look for the Statistics node. It creates an extended statistics object over two columns.

SQL (SQLite) · PostgreSQL sample: simple auto-updatable viewIllustrative · not executed
CREATE OR REPLACE VIEW cb_open_orders AS
SELECT id, customer_id, city, status
FROM cb_orders
WHERE status = 'OPEN'
WITH LOCAL CHECK OPTION;

-- Try editing this view in pgAdmin View/Edit Data.
-- This direct update is also valid SQL for a simple auto-updatable view:
UPDATE cb_open_orders
SET city = 'Mumbai'
WHERE id = 1;

SELECT id, customer_id, city, status
FROM cb_open_orders
ORDER BY id;

This is the kind of simple view you should use to test the v9.19 View/Edit Data improvement. The CHECK OPTION prevents edits that would violate the view predicate.

Interview questions

Why is SELECT version(); not enough to verify a pgAdmin upgrade?

It returns the PostgreSQL server version. pgAdmin is a separate client/admin application, so its version must be checked in the app UI or through the package/install mechanism.

What are extended statistics useful for in PostgreSQL?

They help the planner estimate query cardinality more accurately when relationships between columns matter, such as correlated columns or multi-column distinct counts.

What makes a view a good candidate for auto-updatable editing?

A simple view over one base table with directly mapped columns is a good candidate. Joins, aggregates, grouping, and complex computed columns usually make editing harder or impossible without rules/triggers.

Why test pgAdmin upgrades on a non-production database first?

It verifies that login, saved connections, object browsing, query execution, and editing workflows still work before administrators rely on the upgraded tool for production changes.

Quick quiz

Q1. What is the safest first step before upgrading pgAdmin in a team or production environment?
Q2. Why should pgAdmin 4 v9.19 be prioritized over a routine cosmetic update?
Q3. What is the exact output of the runnable SQLite snippet?

Key takeaways

  • pgAdmin 4 v9.19 should be treated as a priority upgrade because it includes security fixes.
  • Verify the pgAdmin application version separately from the PostgreSQL server version.
  • Test the upgrade on a non-production server before relying on it for production administration.
  • Use a small sample table to validate the new Statistics node for extended statistics.
  • Use simple single-table views when testing View/Edit Data improvements for editable views.

References