Vous n'êtes pas identifié(e).
Pages : 1
Bonjour.
Si j'ai bien compris, la zone wal_buffers (en mémoire partagée) sert à éviter à postgres d'écrire directement les modifications dans les WAL tant que le commit n'a pas été demandé par le client. Une fois le commit envoyé, l'écriture est faite dans le WAL courant et si synchronous_commit=on et wal_sync_method=fsync, le client attendra que les données soitent réellement écrites sur disque.
1) Les écritures dans les WAL sont elles toujours effectuées par le wal_writer ?
2) avec synchronous_commit=on, c'est le commit envoyé par le client qui réveille le wal_writer qui va a) écrire les données dans le WAL et b) faire un fsync
3) dans le cas où synchronous_commit=on le paramètre wal_writer_delay ne sert pas
4) dans le cas où synchronous_commit=off, le paramètre wal_writer_delay est pris en compte, et le wal writer process se reveille tous les wal_writer_delay, il parcourt les wal_buffers et écrit sur disque + fsync toutes les transactions committées qu'il trouve.en outre , on a la garantie que les transactions seront effectivement écrites sur disque au plus tard 3 x wal_writer_delay après que le commit aura été envoyé par le client.
Est ce que j'ai tout bien saisi, notamment le point no 3 ?
Petite précision, je suis en 9.1
Hors ligne
1. Non, elles peuvent être effectuées par les backends.
2. Oui.
3. Non, il sert aussi de délai d'attente pour la boucle principale de wal writer.
4. Non, il écrit les données qu'après COMMIT (si tout tient dans wal_buffers) mais ne force la synchronisation sur disque qu'après 3*wal_writer_delay.
Guillaume.
Hors ligne
Bonjour.
Merci pour ces précisions.
Hors ligne
Pages : 1
