← PostgreSQL DBA← PostgreSQL DBA
PostgreSQL DBAPostgreSQL DBA19 Th7, 2026Jul 19, 202614 phút đọc11 min read

Cài đặt, Thiết lập & Kết nốiInstallation, Setup & Connecting

Thuộc bộ kiến thức PostgreSQL DBA Roadmap.

Tổng quan

Trước khi có thể quản trị một database PostgreSQL, bạn cần một instance đang chạy mà bạn có thể kết nối tới. Nghe có vẻ đơn giản, nhưng cách “đúng” để cài đặt và khởi động PostgreSQL khác nhau khá nhiều tùy vào việc bạn đang thiết lập cho laptop phát triển local, một VM production chạy lâu dài, một container cho CI, hay một managed database trên cloud. Bài viết này đi qua các phương pháp cài đặt (package của distro, official PostgreSQL repository, Docker, và build từ source), cách service được khởi động và điều khiển trên Linux (systemd, pg_ctl, và pg_ctlcluster của Debian), các file cấu hình cốt lõi bạn sẽ đụng tới ngay ngày đầu, và cách kết nối, thao tác thực tế với psql. Kết thúc bằng một bảng so sánh giúp bạn chọn đúng phương pháp cho từng môi trường. Các chủ đề authentication và hardening chuyên sâu hơn được nói ở ./15-security-and-access-control.md; các khái niệm nền tảng về RDBMS ở ./01-introduction-and-rdbms-concepts.md.

Kiến thức nền tảng

Các phương pháp cài đặt

OS package manager (package mặc định của distro). Cách nhanh nhất trên Linux là dùng version PostgreSQL mà distro của bạn cung cấp sẵn.

Debian/Ubuntu:

sudo apt update
sudo apt install -y postgresql postgresql-contrib

RHEL/CentOS/Rocky/Alma (dùng module stream mặc định của distro):

sudo dnf install -y postgresql-server postgresql-contrib
sudo postgresql-setup --initdb
sudo systemctl enable --now postgresql

Vấn đề là: repository của distro thường khá bảo thủ. Ubuntu 22.04 LTS chẳng hạn, mặc định đi kèm PostgreSQL 14, còn module mặc định của RHEL 9 thường chậm hơn bản PostgreSQL mới nhất một hai major version. Nếu bạn cần version mới nhất, các bản vá security theo lịch trình đáng tin cậy, hoặc khả năng chạy song song nhiều major version, hãy dùng official repository thay vào đó.

Official PostgreSQL APT/YUM repository. PostgreSQL Global Development Group (PGDG) duy trì repository riêng cho Debian/Ubuntu và các distro dòng RHEL, được cập nhật trực tiếp bởi chính dự án thay vì maintainer của distro. Đây là cách được khuyến nghị cho bất cứ thứ gì vượt quá một bài test local nhanh, vì nó cho phép bạn chọn chính xác major version (ví dụ 16 hay 17), nhận các bản vá security minor-version ngay khi được phát hành, và khớp với những gì hầu hết các deployment production thực tế đang chạy.

Debian/Ubuntu — thêm PGDG APT repository:

sudo apt install -y curl ca-certificates gnupg
curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | \
  sudo gpg --dearmor -o /usr/share/keyrings/postgresql-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/postgresql-keyring.gpg] \
http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" | \
  sudo tee /etc/apt/sources.list.d/pgdg.list

sudo apt update
sudo apt install -y postgresql-17 postgresql-contrib-17

RHEL/CentOS/Rocky/Alma — thêm PGDG YUM repository:

sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

# tắt module postgresql tích hợp sẵn của distro để tránh xung đột
sudo dnf -qy module disable postgresql

sudo dnf install -y postgresql17-server postgresql17-contrib
sudo /usr/pgsql-17/bin/postgresql-17-setup initdb
sudo systemctl enable --now postgresql-17

Chú ý quy ước đặt tên: package của PGDG nhúng major version vào tên package (postgresql-17, postgresql17-server), đây chính là cơ chế cho phép cài nhiều major version trên cùng một host mà không đè lên nhau — hữu ích khi bạn muốn test một đường nâng cấp trước khi thực hiện thật.

Build từ source. Hiếm khi cần thiết, nhưng quan trọng khi bạn cần một bản build đã patch hoặc tùy chỉnh (ví dụ: test một patch chưa release, áp dụng patch riêng của vendor, bật một build flag mà package không có sẵn, hoặc chạy trên nền tảng không được hỗ trợ chính thức). Phiên bản rút gọn:

sudo apt install -y build-essential libreadline-dev zlib1g-dev bison flex \
  libxml2-dev libxslt1-dev libssl-dev libxslt-dev

curl -O https://ftp.postgresql.org/pub/source/v17.0/postgresql-17.0.tar.bz2
tar xjf postgresql-17.0.tar.bz2
cd postgresql-17.0
./configure --prefix=/usr/local/pgsql-17
make -j$(nproc)
sudo make install

sudo useradd postgres
sudo mkdir -p /usr/local/pgsql-17/data
sudo chown postgres /usr/local/pgsql-17/data
sudo -u postgres /usr/local/pgsql-17/bin/initdb -D /usr/local/pgsql-17/data
sudo -u postgres /usr/local/pgsql-17/bin/pg_ctl -D /usr/local/pgsql-17/data -l logfile start

Với bất cứ mục đích nào khác ngoài việc phát triển và test chính bản thân PostgreSQL, hãy ưu tiên dùng package — build từ source đồng nghĩa với việc bạn mất các bản cập nhật security tự động và tích hợp OS (unit systemd, log rotation, vị trí file chuẩn).

Chạy PostgreSQL trong Docker

Docker rất phù hợp cho phát triển local, pipeline CI, và các môi trường test dùng-rồi-bỏ, nơi bạn muốn có một database sạch trong vài giây và không quan tâm đến cam kết durability dữ liệu lâu dài trên host. Một lần chạy tối thiểu:

docker run -d \
  --name pg-dev \
  -e POSTGRES_PASSWORD=devpassword \
  -e POSTGRES_USER=appuser \
  -e POSTGRES_DB=appdb \
  -p 5432:5432 \
  -v pgdata:/var/lib/postgresql/data \
  postgres:17

Một vài điểm đáng chú ý:

Kết nối tới nó y hệt như bất kỳ server PostgreSQL nào khác:

psql -h localhost -p 5432 -U appuser -d appdb

Docker không phải là cách được khuyến nghị chung để chạy PostgreSQL trong production. Vẫn có thể làm được (và một số nền tảng managed thực ra chạy Postgres containerized bên dưới), nhưng bạn phải tự chịu trách nhiệm về tính đúng đắn của storage driver, chiến lược backup volume, resource limit, và điều phối nâng cấp, mà không có bộ công cụ vận hành mà một cài đặt VM-based hay managed service mang lại. Xem ../devops/en/09-containers.md để biết các mối quan tâm vận hành container tổng quát, và phần cloud bên dưới cho các lựa chọn managed thay thế.

Khái niệm chính

Quản lý service

systemd là cách hầu hết các distro Linux khởi động, dừng, và giám sát tiến trình server PostgreSQL.

sudo systemctl start postgresql       # khởi động cluster
sudo systemctl stop postgresql        # dừng cluster
sudo systemctl restart postgresql     # dừng rồi khởi động lại (ngắt mọi kết nối)
sudo systemctl reload postgresql      # reload config mà không ngắt kết nối
sudo systemctl enable postgresql      # tự khởi động khi boot
sudo systemctl status postgresql      # kiểm tra trạng thái hiện tại

Với package PGDG trên RHEL, tên unit có gồm cả version, ví dụ sudo systemctl start postgresql-17.

pg_ctl là binary điều khiển cluster riêng của PostgreSQL, và đây chính là thứ systemd gọi bên dưới. Nó thao tác trực tiếp trên một data directory (-D), hữu ích khi bạn không dùng service manager của distro, đang debug lỗi khởi động, hoặc đang script hóa việc quản lý cluster:

pg_ctl -D /var/lib/postgresql/17/main start
pg_ctl -D /var/lib/postgresql/17/main stop -m fast
pg_ctl -D /var/lib/postgresql/17/main restart
pg_ctl -D /var/lib/postgresql/17/main reload
pg_ctl -D /var/lib/postgresql/17/main status

Chế độ shutdown -m rất quan trọng: smart đợi client tự ngắt kết nối, fast (mặc định ở các version gần đây) rollback các transaction đang chạy và ngắt kết nối client ngay lập tức, còn immediate hủy bỏ mà không có checkpoint shutdown sạch (crash-recovery sẽ chạy ở lần khởi động kế tiếp).

pg_ctlcluster trên Debian/Ubuntu. Cách đóng gói PostgreSQL của Debian cố ý khác với giả định single-cluster của upstream. Vì Debian muốn bạn có thể cài PostgreSQL 15, 16, và 17 song song — và chạy nhiều hơn một cluster mỗi version nếu muốn — một lệnh pg_ctl trần trụi là không đủ: bạn còn cần biết version nàocluster nào bạn đang muốn nói tới. Bộ công cụ của Debian (postgresql-common) đưa ra khái niệm “cluster” được định danh bởi một version và một tên (cluster mặc định thường tên là main), được theo dõi tại /etc/postgresql/<version>/<cluster-name>/ cho config và /var/lib/postgresql/<version>/<cluster-name>/ cho data. pg_ctlcluster bọc pg_ctl lại với lớp định danh bổ sung đó:

pg_lsclusters                              # liệt kê tất cả cluster, version, port, trạng thái
sudo pg_ctlcluster 17 main start
sudo pg_ctlcluster 17 main stop
sudo pg_ctlcluster 17 main restart
sudo pg_ctlcluster 17 main reload

Bạn cũng có thể tạo thêm cluster cùng hoặc khác version:

sudo pg_createcluster 17 analytics --port=5433
sudo pg_ctlcluster 17 analytics start

Đây chính là cơ chế cho phép một host Debian/Ubuntu duy nhất chạy, chẳng hạn, PostgreSQL 15 cho một ứng dụng legacy trên port 5432 và PostgreSQL 17 cho một service mới trên port 5433, mỗi cái nâng cấp, backup, và cấu hình độc lập với nhau — điều mà mô hình pg_ctl trần của upstream không hỗ trợ tự nhiên.

Cấu hình PostgreSQL

Ba file chi phối phần lớn những gì một DBA mới sẽ đụng tới:

FileMục đích
postgresql.confCài đặt toàn server: bộ nhớ (shared_buffers, work_mem), kết nối (max_connections, listen_addresses), WAL, logging, autovacuum, v.v.
pg_hba.confQuy tắc authentication cho client — host/user/database nào được kết nối, và bằng phương thức auth nào. Được nói sâu hơn ở ./15-security-and-access-control.md.
pg_ident.confÁnh xạ tên định danh OS/external sang tên role PostgreSQL, dùng cùng với authentication peer/ident/gss trong pg_hba.conf.

Vị trí thông thường:

OS / phương pháp cài đặtThư mục configThư mục data
Debian/Ubuntu (PGDG hoặc package distro)/etc/postgresql/<version>/main//var/lib/postgresql/<version>/main/
RHEL/CentOS (package PGDG)/var/lib/pgsql/<version>/data/ (config nằm chung với data theo mặc định)/var/lib/pgsql/<version>/data/
Docker (official image)/var/lib/postgresql/data/ (bên trong container, hoặc volume được mount)như trên
Build từ sourcebất kỳ đâu bạn truyền vào initdb -Dnhư trên

Bạn luôn có thể hỏi trực tiếp server đang chạy xem nó nghĩ file của nó nằm ở đâu:

SHOW config_file;
SHOW hba_file;
SHOW data_directory;

Sau khi sửa postgresql.conf hoặc pg_hba.conf, phần lớn thay đổi chỉ cần reload, không cần restart:

sudo systemctl reload postgresql
# hoặc, ngay trong psql, không cần thoát ra shell:
SELECT pg_reload_conf();

Thay đổi pg_hba.conf luôn có hiệu lực sau reload. Đa số tham số postgresql.conf cũng vậy — nhưng một số được tài liệu đánh dấu là cần restart toàn bộ vì chúng ảnh hưởng đến bố trí shared memory hoặc các thứ khác được cố định lúc khởi động tiến trình: shared_buffers, max_connections, max_worker_processes, wal_buffers, và port là những cái phổ biến nhất. Bạn có thể kiểm tra cột context của một tham số để biết nó cần hành động nào:

SELECT name, context FROM pg_settings WHERE name IN
  ('shared_buffers', 'max_connections', 'work_mem', 'listen_addresses');

context = 'postmaster' nghĩa là cần restart; context = 'sighup' nghĩa là reload là đủ; context = 'user' hoặc 'session' nghĩa là thậm chí có thể đổi theo từng session bằng SET.

Kết nối qua psql

psql là client tương tác chuẩn. Một lần kết nối điển hình:

psql -h db.example.internal -p 5432 -U app_owner -d appdb

Nếu bỏ qua các flag, psql sẽ dùng biến môi trường (PGHOST, PGPORT, PGUSER, PGDATABASE) rồi đến các giá trị mặc định hợp lý (Unix socket, user OS hiện tại, một database trùng tên user đó). Sau khi kết nối, bạn ở trong một prompt tương tác nơi câu lệnh SQL chạy nguyên trạng và các meta-command bắt đầu bằng dấu gạch chéo ngược điều khiển chính client:

psql session
  1. 01appdb=> \l
  2. 02appdb=> \c otherdb
  3. 03otherdb=> \dt
  4. 04otherdb=> \d accounts
  5. 05otherdb=> \du
  6. 06otherdb=> \x
  7. 07otherdb=> SELECT * FROM accounts LIMIT 3;
  8. 08otherdb=> \q

Các meta-command hữu ích nhất cần biết ngay từ ngày đầu:

Meta-commandChức năng
\lLiệt kê tất cả database
\c dbnameKết nối sang database khác (tùy chọn \c dbname user host port)
\dtLiệt kê table trong schema search path hiện tại
\d tablenameMô tả một table: cột, kiểu dữ liệu, index, constraint, foreign key
\duLiệt kê role và thuộc tính của chúng (superuser, login, v.v.)
\dnLiệt kê schema
\diLiệt kê index
\xBật/tắt output mở rộng (“dạng dọc”) — cực hữu ích với row rộng
\timingBật/tắt hiển thị thời gian thực thi câu query
\eMở query buffer hiện tại trong $EDITOR
\i file.sqlThực thi câu lệnh SQL từ một file
\conninfoHiện chi tiết kết nối hiện tại (host, port, user, database)
\qThoát psql

Triển khai trên cloud

Ngoài tự cài đặt trên VM, bạn có thể dùng các dịch vụ PostgreSQL managed như AWS RDS/Aurora, GCP Cloud SQL, hoặc Azure Database for PostgreSQL. Đánh đổi vận hành ở đây khá rõ: managed service lo giúp bạn việc vá lỗi (patching), backup, và high availability, nhưng đổi lại bạn thường mất quyền superuser đầy đủ và bị giới hạn một số extension không được nhà cung cấp hỗ trợ. Tự quản lý trên VM cho bạn toàn quyền kiểm soát nhưng bạn phải tự lo mọi khâu vận hành đó. Xem chi tiết ở ../cloud/README.md.

Best Practices

Tài liệu tham khảo

Part of the PostgreSQL DBA Roadmap knowledge base.

Overview

Before you can administer a PostgreSQL database, you need a running instance you can reach. That sounds trivial, but the “right” way to install and start PostgreSQL differs quite a bit depending on whether you’re setting up a laptop for local development, a long-lived production VM, a container for CI, or a managed cloud database. This note walks through the installation methods (distro packages, the official PostgreSQL repositories, Docker, and source builds), how the service is started and controlled on Linux (systemd, pg_ctl, and Debian’s pg_ctlcluster), the core configuration files you’ll touch on day one, and how to actually connect and poke around with psql. It closes with a comparison table to help you pick the right approach for a given environment. Deeper authentication and hardening topics are covered separately in ./15-security-and-access-control.md; foundational RDBMS concepts are in ./01-introduction-and-rdbms-concepts.md.

Fundamentals

Installation methods

OS package managers (distro-default packages). The fastest path on Linux is to use whatever PostgreSQL version your distribution ships.

Debian/Ubuntu:

sudo apt update
sudo apt install -y postgresql postgresql-contrib

RHEL/CentOS/Rocky/Alma (using the distro’s own module stream):

sudo dnf install -y postgresql-server postgresql-contrib
sudo postgresql-setup --initdb
sudo systemctl enable --now postgresql

The catch: distro repositories are conservative. Ubuntu 22.04 LTS, for example, ships PostgreSQL 14 by default, and RHEL 9’s default module is often one or two major versions behind the latest PostgreSQL release. If you need the current major version, security patches on a predictable schedule, or the ability to run several major versions side by side, use the official repositories instead.

Official PostgreSQL APT/YUM repositories. The PostgreSQL Global Development Group (PGDG) maintains its own repositories for Debian/Ubuntu and RHEL-family distros, updated directly by the project rather than the distro maintainers. This is the recommended approach for anything beyond a quick local test, because it lets you pick an exact major version (e.g., 16 vs 17), gets you minor-version security fixes as soon as they’re released, and matches what most production deployments actually run.

Debian/Ubuntu — add the PGDG APT repository:

sudo apt install -y curl ca-certificates gnupg
curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | \
  sudo gpg --dearmor -o /usr/share/keyrings/postgresql-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/postgresql-keyring.gpg] \
http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" | \
  sudo tee /etc/apt/sources.list.d/pgdg.list

sudo apt update
sudo apt install -y postgresql-17 postgresql-contrib-17

RHEL/CentOS/Rocky/Alma — add the PGDG YUM repository:

sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

# disable the distro's built-in postgresql module so it doesn't conflict
sudo dnf -qy module disable postgresql

sudo dnf install -y postgresql17-server postgresql17-contrib
sudo /usr/pgsql-17/bin/postgresql-17-setup initdb
sudo systemctl enable --now postgresql-17

Note the naming convention: PGDG packages embed the major version in the package name (postgresql-17, postgresql17-server), which is exactly what allows multiple major versions to be installed on the same host without clobbering each other — useful for testing an upgrade path before committing to it.

Building from source. Rarely necessary, but it matters when you need a patched or custom build (e.g., testing an unreleased patch, applying a vendor-specific patch, enabling a build flag that packages don’t ship with, or running on an unsupported platform). The short version:

sudo apt install -y build-essential libreadline-dev zlib1g-dev bison flex \
  libxml2-dev libxslt1-dev libssl-dev libxslt-dev

curl -O https://ftp.postgresql.org/pub/source/v17.0/postgresql-17.0.tar.bz2
tar xjf postgresql-17.0.tar.bz2
cd postgresql-17.0
./configure --prefix=/usr/local/pgsql-17
make -j$(nproc)
sudo make install

sudo useradd postgres
sudo mkdir -p /usr/local/pgsql-17/data
sudo chown postgres /usr/local/pgsql-17/data
sudo -u postgres /usr/local/pgsql-17/bin/initdb -D /usr/local/pgsql-17/data
sudo -u postgres /usr/local/pgsql-17/bin/pg_ctl -D /usr/local/pgsql-17/data -l logfile start

For anything other than development and testing of PostgreSQL itself, prefer packages — you lose automatic security updates and OS integration (systemd units, log rotation, standard file locations) when building from source.

Running PostgreSQL in Docker

Docker is an excellent fit for local development, CI pipelines, and disposable test environments where you want a clean database in seconds and don’t care about long-term data durability guarantees on the host. A minimal run:

docker run -d \
  --name pg-dev \
  -e POSTGRES_PASSWORD=devpassword \
  -e POSTGRES_USER=appuser \
  -e POSTGRES_DB=appdb \
  -p 5432:5432 \
  -v pgdata:/var/lib/postgresql/data \
  postgres:17

A few things worth unpacking:

Connect to it exactly as you would any other PostgreSQL server:

psql -h localhost -p 5432 -U appuser -d appdb

Docker is not generally the recommended way to run PostgreSQL in production. It can be done (and some managed platforms do run containerized Postgres under the hood), but you take on responsibility for storage driver correctness, volume backup strategy, resource limits, and upgrade orchestration yourself, without the operational tooling a VM-based install or a managed service gives you. See ../devops/en/09-containers.md for general container operational concerns, and the cloud section below for managed alternatives.

Key Concepts

Service management

systemd is how most Linux distributions start, stop, and supervise the PostgreSQL server process.

sudo systemctl start postgresql       # start the cluster
sudo systemctl stop postgresql        # stop the cluster
sudo systemctl restart postgresql     # stop then start (drops all connections)
sudo systemctl reload postgresql      # reload config without dropping connections
sudo systemctl enable postgresql      # start automatically on boot
sudo systemctl status postgresql      # check current state

On PGDG RHEL packages, the unit name includes the version, e.g. sudo systemctl start postgresql-17.

pg_ctl is PostgreSQL’s own cluster-control binary, and it’s what systemd calls under the hood. It operates directly on a data directory (-D), which makes it useful when you’re not using a distro’s service manager, are debugging startup issues, or are scripting cluster management:

pg_ctl -D /var/lib/postgresql/17/main start
pg_ctl -D /var/lib/postgresql/17/main stop -m fast
pg_ctl -D /var/lib/postgresql/17/main restart
pg_ctl -D /var/lib/postgresql/17/main reload
pg_ctl -D /var/lib/postgresql/17/main status

The -m shutdown mode matters: smart waits for clients to disconnect, fast (the default in recent versions) rolls back active transactions and disconnects clients immediately, and immediate aborts without a clean shutdown checkpoint (crash-recovery will run on next start).

pg_ctlcluster on Debian/Ubuntu. Debian’s PostgreSQL packaging deliberately deviates from upstream’s single-cluster assumption. Because Debian wants you to be able to install PostgreSQL 15, 16, and 17 side by side — and run more than one cluster per version if you want — a bare pg_ctl call isn’t enough: you also need to know which version and which cluster you mean. Debian’s tooling (postgresql-common) introduces the concept of a “cluster” identified by a version and a name (the default cluster is usually named main), tracked under /etc/postgresql/<version>/<cluster-name>/ for config and /var/lib/postgresql/<version>/<cluster-name>/ for data. pg_ctlcluster wraps pg_ctl with that extra addressing:

pg_lsclusters                              # list all clusters, versions, ports, status
sudo pg_ctlcluster 17 main start
sudo pg_ctlcluster 17 main stop
sudo pg_ctlcluster 17 main restart
sudo pg_ctlcluster 17 main reload

You can also create additional clusters of the same or different versions:

sudo pg_createcluster 17 analytics --port=5433
sudo pg_ctlcluster 17 analytics start

This is the mechanism that lets a single Debian/Ubuntu host run, say, PostgreSQL 15 for a legacy app on port 5432 and PostgreSQL 17 for a new service on port 5433, each independently upgradable, backed up, and configured — something upstream’s plain pg_ctl model doesn’t natively support.

Configuring PostgreSQL

Three files govern most of what you’ll touch as a new DBA:

FilePurpose
postgresql.confServer-wide settings: memory (shared_buffers, work_mem), connections (max_connections, listen_addresses), WAL, logging, autovacuum, etc.
pg_hba.confClient authentication rules — which hosts/users/databases can connect, and with what auth method. Covered in depth in ./15-security-and-access-control.md.
pg_ident.confMaps OS/external identity names to PostgreSQL role names, used together with peer/ident/gss authentication in pg_hba.conf.

Typical locations:

OS / install methodConfig directoryData directory
Debian/Ubuntu (PGDG or distro package)/etc/postgresql/<version>/main//var/lib/postgresql/<version>/main/
RHEL/CentOS (PGDG package)/var/lib/pgsql/<version>/data/ (config lives alongside data by default)/var/lib/pgsql/<version>/data/
Docker (official image)/var/lib/postgresql/data/ (inside container, or the mounted volume)same
Built from sourcewherever you passed to initdb -Dsame

You can always ask the running server where it thinks its files are:

SHOW config_file;
SHOW hba_file;
SHOW data_directory;

After editing postgresql.conf or pg_hba.conf, most changes just need a reload, not a restart:

sudo systemctl reload postgresql
# or, from inside psql, without shelling out:
SELECT pg_reload_conf();

pg_hba.conf changes always take effect on reload. Most postgresql.conf parameters do too — but a subset are marked in the docs as requiring a full restart because they affect shared memory layout or other things fixed at process startup: shared_buffers, max_connections, max_worker_processes, wal_buffers, and port are the common ones. You can check a parameter’s context column to know which action it needs:

SELECT name, context FROM pg_settings WHERE name IN
  ('shared_buffers', 'max_connections', 'work_mem', 'listen_addresses');

context = 'postmaster' means restart is required; context = 'sighup' means a reload is enough; context = 'user' or 'session' means it can even be changed per-session with SET.

Connecting via psql

psql is the standard interactive client. A typical connection:

psql -h db.example.internal -p 5432 -U app_owner -d appdb

If you omit flags, psql falls back to environment variables (PGHOST, PGPORT, PGUSER, PGDATABASE) and then to sensible local defaults (Unix socket, current OS user, a database matching that username). Once connected, you’re in an interactive prompt where SQL statements run as-is and backslash-prefixed meta-commands control the client itself:

psql session
  1. 01appdb=> \l
  2. 02appdb=> \c otherdb
  3. 03otherdb=> \dt
  4. 04otherdb=> \d accounts
  5. 05otherdb=> \du
  6. 06otherdb=> \x
  7. 07otherdb=> SELECT * FROM accounts LIMIT 3;
  8. 08otherdb=> \q

The most useful meta-commands to know from day one:

Meta-commandWhat it does
\lList all databases
\c dbnameConnect to a different database (optionally \c dbname user host port)
\dtList tables in the current schema search path
\d tablenameDescribe a table: columns, types, indexes, constraints, foreign keys
\duList roles and their attributes (superuser, login, etc.)
\dnList schemas
\diList indexes
\xToggle expanded (“vertical”) output — invaluable for wide rows
\timingToggle display of query execution time
\eOpen the current query buffer in $EDITOR
\i file.sqlExecute SQL commands from a file
\conninfoShow current connection details (host, port, user, database)
\qQuit psql

Best Practices

References