Örnek sorular
Pg OperationsZorluk 1
psql içinde \dt tabloları listeler, \d orders bir tablonun kolonlarını ve index'lerini açıklar. Bu iki komut neden bir Go uygulamasının, tel üzerinden PostgreSQL'e gönderdiği SQL query string'i içinde kullanılamaz?
- aÇünkü
\dt/\d yalnızca psql meta-komutlarıdır, client tarafında genişletilir, sunucunun ayrıştırdığı SQL değildir✓ - bÇünkü sunucu SQL'i yalnızca postgres superuser hesabından kabul eder, uygulama rolünden asla
- cÇünkü
\dt ve \d superuser oturumu gerektirir ve uygulama rolleri böyle bir oturum açamaz - dÇünkü bu komutlar yalnızca PostgreSQL 18'de vardır ve pgx gibi client library'lerde kullanılamaz
Açıklama:Ters eğik çizgiyle başlayan komutlar psql'e özgü meta-komutlardır; sunucuya bir şey gönderilmeden ÖNCE psql client'ının kendisi tarafından yorumlanıp genişletilir — sunucunun SQL parser'ının \dt veya \d diye bir kavramı yoktur. pgx gibi bir application driver yalnızca SQL metni gönderir, bu yüzden catalog'u doğrudan sorgulamalıdır (ör. information_schema veya pg_catalog).
Pg OperationsZorluk 1
psql içinde \l çalıştırmak Name, Owner, Encoding gibi kolonları olan bir tablo basar. Bu meta-komut aslında neyi listeler?
- aO anda bağlı olunan veritabanı içindeki tabloları
- bBağlı olunan PostgreSQL sunucusunda/cluster'da var olan veritabanlarını✓
- cBağlı olunan veritabanında o anda kurulu olan extension'ları
- dSunucuya o anda bağlı açık client bağlantılarını
Açıklama:\l (list), o anda bağlı olunan cluster'daki her veritabanını, owner/encoding/erişim yetkisiyle birlikte sunucudan sorgular — bir veritabanı içindeki tablolarla (\dt), kurulu extension'larla (\dx) veya aktif bağlantılarla (pg_stat_activity) ilgisi yoktur.
Pg OperationsZorluk 1
psql'de \du, Role name ve Attributes kolonlarına sahip bir List of roles tablosu basar (ör. Superuser, Create role). Bu komut ne gösterir?
- aO anda aktif TCP bağlantısıyla veritabanına giriş yapmış kullanıcıları
- bMevcut kullanıcının erişim yetkisi verilmiş olduğu tabloları
- cSunucuda tanımlı rolleri ve her birinin taşıdığı yetki/attribute'ları✓
- dMevcut veritabanında var olan şemaları ve owner'larını
Açıklama:\du, cluster'daki her rolü, attribute'larıyla birlikte listeler (superuser mi, rol oluşturabiliyor mu, veritabanı oluşturabiliyor mu, login yetkisi var mı, vb). Aktif bağlantılar pg_stat_activity'den, verilmiş tablo erişimi \dp/information_schema'dan, şemalar ise \dn'den gelir.
Pg OperationsZorluk 1
psql oturumunda bir kez \timing yazıp bir sorgu çalıştırdıktan sonra psql, sonucun altına Time: 0.075 ms gibi ek bir satır basar. \timing'i ikinci kez yazmak ne yapar?
- aZamanlayıcıyı sıfırlar, böylece bir sonraki sorgunun süresi sıfır milisaniyeden ölçülür
- bpsql'i, sorgu başına değil tüm oturum boyunca kümülatif süre gösterecek şekilde değiştirir
- cPostgreSQL'e sorgu çalışma süresini sunucu log dosyasına yazdırır
- dÖzelliği kapatır, böylece sonraki sorgu sonuçlarının altında artık
Time: satırı basılmaz✓
Açıklama:\timing bir toggle'dır: her yazışında psql, her komuttan sonra geçen gerçek-zaman süresini gösterme/göstermeme arasında geçiş yapar; bu, psql oturumunda client tarafında basılır — sunucu log'una veya herhangi bir sayaca dokunmaz.
Pg OperationsZorluk 1
Bir junior geliştirici, PostgreSQL'e aynı anda 200 bağlantı açmanın, sunucu host'unun process listesini (ps aux) yaklaşık 200 satır büyüttüğünü fark ediyor. Neden?
- aPostgreSQL process-per-connection modeli kullanır: postmaster her client bağlantısı için ayrı bir backend OS process'i fork eder✓
- bPostgreSQL tek bir paylaşılan process içinde bağlantı başına bir thread açar,
ps aux ise thread'leri yanlışlıkla process olarak listeler - cHer bağlantı, PostgreSQL'e o oturuma özel bir arka plan autovacuum worker'ı başlatmasına neden olur
- dBu yalnızca
max_connections varsayılan değerinde bırakıldığında olur, değer artırılınca ortadan kalkar
Açıklama:PostgreSQL'in klasik mimarisi, her client bağlantısı için tam bir OS backend process'i (thread değil) fork eder; bağlantı sayısının doğrudan process listesinde görünmesinin nedeni budur — ve bağlantıların bedava olmamasının da nedeni budur: her biri gerçek bellek ve OS zamanlama yükü taşır.
Pg OperationsZorluk 1
SHOW statement_timeout;
-- statement_timeout
-- -------------------
-- 0
SET statement_timeout = '2s';
SHOW statement_timeout;
-- statement_timeout
-- -------------------
-- 2s
Bu oturum kapandıktan ve yeni bir oturum bağlandıktan sonra
SHOW statement_timeout; ne rapor eder?
- a
2s, çünkü LOCAL olmadan SET, değeri tüm gelecek bağlantılar için kalıcı yapar - b
0 (ya da sunucu genelindeki varsayılan her ne ise), çünkü SET değeri yalnızca mevcut oturum için değiştirir✓ - cHata, çünkü
statement_timeout SET ile değil yalnızca ALTER SYSTEM ile değiştirilebilir - d
2s, çünkü PostgreSQL oturum-bazlı SET değerlerini veritabanının sistem catalog'unda saklar
Açıklama:Düz SET, bir çalışma-zamanı parametresini yalnızca mevcut oturumun ömrü boyunca (ya da reset edilene kadar) değiştirir; yeni bir bağlantıya asla kalıcı geçmez. Bir değeri tüm gelecek oturumlar için kalıcı yapmak ALTER SYSTEM, ALTER DATABASE ... SET ya da postgresql.conf'ta değişiklik gerektirir — bunların hiçbiri burada olmuyor.