PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 Re : Général » Exploitation des commentaires Postgresql » 05/02/2024 12:21:54

Bonjour,
Certains outils permettent de générer de la documentation en les exploitant. Je pense notamment à tbls : https://github.com/k1LoW/tbls
Et à schemaspy https://schemaspy.org/

#2 Re : Site PostgreSQL.fr » Connexion PostgreSQL avec Excel » 15/10/2015 10:44:14

Cette présentation de Jean-Marc Guazzo devrait vous aider : "Jean-Marc Guazzo de SQIG Inc (Québec, Canada) : Office, .NET & … PostgreSQL : tiercé gagnant pour les institutions publiques "
http://www.postgresql-sessions.org/7/start

#3 Re : Optimisation » Optimisation multi instances » 21/04/2015 15:05:25

Je m’immisce dans ce sujet, si vous en avez la possibilité je vous conseille de partir sur une version de red hat plus récente.
La 5.4 date de 2009, en général la 5.X ne sera supporté par red hat que jusqu'en 2017. 2 ans ça fait court. Par ailleurs les versions 6, et à fortiori 7 disposent de noyaux plus récents.

#4 Re : Général » Optimisation de la vitesse d'insertion d'une bd importante » 03/02/2015 11:09:19

Une solution serait peut être d'avoir plusieurs grappes de disques.
Un ensemble où il y a la base, un autre où il y a les wal.

Après il faudrait gratter pour savoir quel est le facteurs limitant, est-ce les disques, le cpu?

#5 Re : Réplication » Le paramètre synchronous_standby_names surcharge synchronous_commit? » 04/12/2014 12:03:11

Merci, ça confirme mon intuition.

Je poste le lien pour d'autres lecteurs vers la section de la doc qui détaille le comportement de postgres quand il y a plusieurs esclaves synchrones (ou potentiel synchrone) dans synchronous_standby_names :

Specifies a comma-separated list of standby names that can support synchronous replication, as described in Section 25.2.7. At any one time there will be at most one active synchronous standby; transactions waiting for commit will be allowed to proceed after this standby server confirms receipt of their data. The synchronous standby will be the first standby named in this list that is both currently connected and streaming data in real-time (as shown by a state of streaming in the pg_stat_replication view). Other standby servers appearing later in this list represent potential synchronous standbys. If the current synchronous standby disconnects for whatever reason, it will be replaced immediately with the next-highest-priority standby. Specifying more than one standby name can allow very high availability.

http://www.postgresql.org/docs/9.3/stat … ION-MASTER

#6 Réplication » Le paramètre synchronous_standby_names surcharge synchronous_commit? » 04/12/2014 00:03:11

anayrat
Réponses : 2

Bonjour,

J'effectue quelques tests sur un postgres 9.3. J'ai une config assez simple, un maitre et un esclave avec une streaming replication.
J'ai constaté que du moment où j'avais un esclave dans la ligne synchronous_standby_names le serveur était synchrone avec cet esclave même si je place le synchronous_commit à local ou remote_write.

En revanche, si je commente la ligne synchronous_standby_names le maitre devient asynchrone avec l'esclave que ce soit en "local" ou "remote_write". En regardant la doc le async est normal en remote_write sans "synchronous_standby_names" en revanche je ne comprends pas pourquoi il est n'est pas async quand je spécifie local et l'esclave dans "synchronous_standby_names" ?

Specifies whether transaction commit will wait for WAL records to be written to disk before the command returns a "success" indication to the client. Valid values are on, remote_write, local, and off. The default, and safe, setting is on. When off, there can be a delay between when success is reported to the client and when the transaction is really guaranteed to be safe against a server crash. (The maximum delay is three times wal_writer_delay.) Unlike fsync, setting this parameter to off does not create any risk of database inconsistency: an operating system or database crash might result in some recent allegedly-committed transactions being lost, but the database state will be just the same as if those transactions had been aborted cleanly. So, turning synchronous_commit off can be a useful alternative when performance is more important than exact certainty about the durability of a transaction. For more discussion see Section 29.3.


If synchronous_standby_names is set, this parameter also controls whether or not transaction commits will wait for the transaction's WAL records to be replicated to the standby server. When set to on, commits will wait until a reply from the current synchronous standby indicates it has received the commit record of the transaction and flushed it to disk. This ensures the transaction will not be lost unless both primary and standby suffer corruption of their database storage. When set to remote_write, commits will wait until a reply from the current synchronous standby indicates it has received the commit record of the transaction and written it out to the standby's operating system, but the data has not necessarily reached stable storage on the standby. This setting is sufficient to ensure data preservation even if the standby instance of PostgreSQL were to crash, but not if the standby suffers an operating-system-level crash.


When synchronous replication is in use, it will normally be sensible either to wait for both local flush to disk and replication of WAL records, or to allow the transaction to commit asynchronously. However, the setting local is available for transactions that wish to wait for local flush to disk, but not synchronous replication. If synchronous_standby_names is not set, the settings on, remote_write and local all provide the same synchronization level: transaction commits only wait for local flush to disk.


This parameter can be changed at any time; the behavior for any one transaction is determined by the setting in effect when it commits. It is therefore possible, and useful, to have some transactions commit synchronously and others asynchronously. For example, to make a single multistatement transaction commit asynchronously when the default is the opposite, issue SET LOCAL synchronous_commit TO OFF within the transaction.

http://www.postgresql.org/docs/9.3/stat … OUS-COMMIT

J'imagine que c'est un comportement normal mais je trouve que ce n'est pas explicité dans la documentation? Any idea? Merci

#7 Re : Optimisation » Ratio Lecture/Ecriture » 08/10/2014 15:06:52

Bonjour,
Vous souhaitez avoir un aperçu des lectures écritures au niveau système de fichier ou au niveau de la base de données?

Je pose la question car vous semblez mélanger les deux, des lectures sur la bdd peuvent taper dans le cache de postgres ce qui n'entraine pas de lecture sur le disque. De même que les écritures peuvent être confondues si vous n'avez pas séparé les journaux de transactions, une première écriture dans les journaux, puis en fonction de l'activité un checkpoint de vos journaux vers la base.

Je connais deux outils que je trouve assez sympa pour les lectures/ecritures : atop et dstat. Il y a même un démon atop qui permet de conserver un historique des statistiques.

Pied de page des forums

Propulsé par FluxBB