Mariel Cherkassky wrote: > Yeah, so basically if we open a transaction and we do some insert queries, until the transaction > is commited the changes(the wal data and not the blocked that are chaned) are kept in the wal buffers ? > . When the user commits the transaction, the wal buffer(only the transaction log of that specific > transaction ?) is written to wal files. When the database completes saving the content of the > transaction log into the wal files, the commit completes. Did I got it right ? WAL can be written to file before the transaction commits. Otherwise the size of a transaction would be limited. Only at commit time, it has to be written out and flushed to disk. > What I meant, when checkpoint occurs, it reads the wal files created since last checkpoint, > and does those changing on the data blocks on the disk ? I was not talking about dirty blocks > from shared_buffer. No, PostgreSQL does not read the WAL files when it performs a checkpoint. When data are modified, first WAL is written, then it is written to shared buffers. The checkpoint flushes dirty pages in shared buffers to disk. > > so I'f I want have replication slot and wal_keep_segment is 0 after the archiving of > > the wal it should be recycled/deleted ? Only if it is older than the position of the replication slot. > > So basically having wal_keep_segments and replication slot configured together is a mistake right ? > > In that case, if you have both configured, and you set wal_keep_segments to 0, the db should > > delete all the unused wals ? It is pointless to have both a replication slot and wal_keep_segments, yes. Setting wal_keep_segments to 0 is the right move in that case and should reduce pg_xlog size in time. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com
