Transaction Isolation Level - Serializable

Örnek

Şöyle yaparız

BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SELECT *
FROM doctors
WHERE status = 'ON_CALL'; 

Örnek

40001 hatası verir. Elimizde şöyle bir kod olsun.

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Isolation;
import org.springframework.transaction.annotation.Transactional;

@Service
public class OrderService {
    @Transactional(isolation = Isolation.SERIALIZABLE)
    public OrderResult placeOrder(OrderRequest request) {
        // 1. Read current database state (e.g., check stock count)
        
        // 2. Validate business rules (e.g., is stock > 0?)
        
        // 3. Apply database modifications (e.g., deduct stock, save order)
        
        return new OrderResult("Success");
    }
}

Şöyle yaparız

import org.springframework.dao.PessimisticLockingFailureException;
import org.springframework.stereotype.Component;
import java.sql.SQLException;

@Component
public class TransactionRetryManager {
  private final OrderService orderService;
  public TransactionRetryManager(OrderService orderService) {
    this.orderService = orderService;
  }
  public OrderResult processWithRetry(OrderRequest request) {
    int maxAttempts = 3;
    for (int attempt = 1; attempt <= maxAttempts; attempt++) {
      try {
        // Try executing the transactional method
        return orderService.placeOrder(request);
      } catch (RuntimeException ex) {
        // Check if this exception was caused by Postgres SQLSTATE 40001
        if (!isSerializationFailure(ex)) {
          throw ex; // It's a different error (e.g., bad SQL syntax), give up immediately
        }
        // If we ran out of attempts, stop retrying and throw the error
        if (attempt == maxAttempts) {
          throw ex;
        }
                
        // Optional: Add a brief pause (backoff) here before trying again
       }
     }
     throw new IllegalStateException("Unexpected retry state reached");
  }

  private boolean isSerializationFailure(RuntimeException ex) {
    // Look down the exception chain to find the root JDBC SQLException
    Throwable cause = ex.getCause();
    while (cause != null) {
      if (cause instanceof SQLException sqlEx) {
        // Deterministically match the exact Postgres serialization error code
        if ("40001".equals(sqlEx.getSQLState())) {
          return true;
        }
      }
      cause = cause.getCause();
    }
    return false;
  }
}

Patroni - High Availability İçindir

Giriş

Açıklaması şöyle. Yani primary_restart_timeout süresi içinde PG ayağa kalkarsa lider değişmez.

Patroni ile yönetilen bir PostgreSQL cluster’ında lider restart olduğu halde lider neden değişmez?

HA denince akla genelde “lider gittiği an replica devreye girer” fikri geliyor. Oysa ister MSSQL Always On olsun ister Patroni, iki tarafta da kısa ve toparlanabilir bir kesinti için hemen failover yapılmıyor. Patroni tarafında bunun nasıl işlediğine bakalım.

Patroni liderliği DCS üzerinde tutulan bir lock ile yönetiyor. Lider node’daki Patroni bu lock’u düzenli olarak yeniledikçe diğer node’lar lider olmaya kalkmıyor. PostgreSQL process’i çökse bile Patroni ayaktaysa lock yenilenmeye devam ediyor ve Patroni PG’yi aynı node üzerinde tekrar başlatıyor. Failover ancak lock’un süresi dolduğunda ya da PG belirlenen süre içinde ayağa kalkamadığında devreye giriyor.

Bu tercih kesintiyi uzatıyor gibi görünse de çoğu zaman tam tersi oluyor. Yerinde bir restart genelde birkaç saniyede tamamlanır. Failover’da ise önce liderin gerçekten gittiğinden emin olmak için beklemek, ardından promote ve trafiğin yeni lidere yönlenmesi gerekir. Asenkron replikasyonda buna bir de veri kaybı riski eklenir.

Failover olduğunda işin bir de timeline tarafı var. Promote olan replica yeni bir timeline açıyor ve eski timeline’dan hangi noktada ayrıldığını bir history dosyasına yazıyor. Eski lider geri döndüğünde Patroni onun son WAL konumunu bu ayrışma noktasıyla karşılaştırıyor.

Eski liderde yeni liderin hiç görmediği kayıtlar yoksa node doğrudan replica olarak devam ediyor. Varsa ve use_pg_rewind açıksa pg_rewind bu kayıtları atıp node’u yeni liderle hizalıyor. Rewind’in çalışabilmesi için data_checksums ya da wal_log_hints açık olmalı. Rewind kapalıysa ya da başarısız olursa geriye reinit, yani replica’yı baştan kopyalamak kalıyor.

Burada sık gözden kaçan bir detay var. Asenkron modda rewind’in attığı kayıtlar, uygulamaya commit onayı verilmiş gerçek veriler olabilir. Senkron modda ise atılan kayıtlar henüz onaylanmamış işlemler. Rewind iki durumda da çalışabilir ama sonuçları aynı değil.

Bir DBA olarak bu LSN karşılaştırmalarını çoğu zaman elle yapmıyoruz, o işi Patroni yapıyor. Bize düşen, patronictl list çıktısını ve Patroni loglarını doğru okumak. Node streaming durumdaysa ve timeline’ı liderle aynıysa sorun yok. Değilse sebebi loglarda 

Graph Database

Giriş

Açıklaması şöyle

PostgreSQL, in their latest release, version 19, has shipped property graphs.

We can now define a graph over our existing relational tables and query them. So, no need to install new extensions or run migrations.

Let me give you an example. If you already have tables like users, follows, posts, today, we would need to write joins to answer questions like "who follows who" or "which posts got liked by friends of friends."

But with this, we can just declare users as vertices and follows as edges, then query the relationship directly using pattern-matching syntax instead of chaining joins. And, this is apt for all graph use cases like:

- social graphs

- fraud detection

- data lineage

- dependency graphs, etc.

Btw, this graph is a read-only view over your existing tables, and a really powerful part is that we can mix a graph query and a normal SQL query in the same statement.

Of course, it is not as performant or powerful as regular graph databases (yet), but it is a pretty solid choice when you are in your 0 to 1 journey.

You know things are serious when PG gets it as first-class support. Graphs are certainly cool again. Also, looks like this will forever remain true:

Just use Postgres :)

In-memory database

Giriş

Açıklaması şöyle

Did you know you can make PostgreSQL run almost fully in-memory?

Postgres docs explicitly describe a non-durable setup where you can put the whole data directory on a RAM disk and disable:

fsync: don’t force writes to durable storage

synchronous_commit: don’t make COMMIT wait for WAL to flush

You basically trade durability for speed.

Pretty interesting that PostgreSQL can be pushed this far without switching to a separate in-memory database.

It’s a game-changer for running in CI, it’s so much faster

postgresql.conf Dosyası - work_mem Alanı

Açıklaması şöyle

PostgreSQL uses the work_mem configuration parameter to determine the amount of memory available for sorting and hashing operations. Properly configuring work_mem can greatly impact the performance of queries involving sorting or hash joins.

Configuring the work_mem parameter in PostgreSQL is crucial for optimizing query performance, but it requires finding the right balance. Increasing work_mem on high-performance systems can speed up sorting and hashing operations, leading to faster query execution.

However, setting it too high might cause excessive memory usage and potential memory contention, impacting overall performance. To determine the ideal work_mem value, start conservatively and monitor system performance while gradually increasing it. Keep a close watch on memory consumption and query execution times. Additionally, consider using partitioned queries or limiting result set sizes for resource-intensive queries to prevent excessive memory usage. Striking the right balance ensures PostgreSQL operates efficiently without overwhelming system memory and maximizes the benefits of work_mem for improved query performance.

Örnek

Şöyle yaparız

SET work_mem = "128MB";

Örnek

Şöyle

Sorgum neden bu kadar yavaş diye saatlerce baktın. Sorun sorguda değildi.

EXPLAIN çıktısında "external merge Disk" yazıyordu. PostgreSQL sıralama işlemini RAM'de bitirememiş, diske taşmıştı. work_mem 4MB'da kalmış, varsayılan değerden hiç çıkmamıştık.

PostgreSQL bellek yetmediğinde hata vermez, sessizce diske geçer. Sorgu yine de sonuç döndürür ama 200 milisaniyede bitmesi gereken iş 4 saniyeye uzar. Fark edilmesi zordur, çünkü sistem sizi uyarmaz.

PostgreSQL Health Check List

Giriş

Yazıyı buradan aldım

The PostgreSQL health check I run on every new database.

Doesn't matter if it's a fresh install or a production instance someone hands me. Same checklist, every time.

Here's what I look at first:

Autovacuum settings. Is it actually running? Are the thresholds sane for the table sizes? Default scale_factor of 0.2 is fine for small tables but terrible for anything with millions of rows.

Missing indexes. I check pg_stat_user_tables for tables with high sequential scan counts relative to index scans. If a table has 500k seq_scans and 12 idx_scans, something is wrong.

Connection limits. How many connections are configured vs. how many are actually in use? I've seen instances running at 95% of max_connections with no connection pooler in sight.

Replication lag. If there's a replica, how far behind is it? Seconds of lag might be acceptable. Minutes means trouble.

Table bloat. Dead tuples piling up means autovacuum is either misconfigured or can't keep up. This is where most "the database is slow" complaints start.

Idle transactions. Long-running idle-in-transaction sessions hold locks and block autovacuum. They're silent killers.

I got tired of running through this manually on every instance, so I built these checks (and about 50 more) into mydba.dev. It runs them regularly and flags anything that needs attention.

Backup Araçları

Databasus

Açıklaması şöyle

Databasus is an industry standard for PostgreSQL backup tools, offering scheduled backups with compression and encryption for both individual developers and enterprise teams.