La valeur par défaut du paramètre de serveur max_wal_senders, définie lorsque vous approvisionnez l’instance Azure Database pour PostgreSQL – Serveur flexible, ne doit jamais être diminuée en dessous de 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez la nécessité d’augmenter max_wal_senders vers une valeur beaucoup plus élevé pour pouvoir faire face à la réplication logique d’un nombre considérable de tables, rappelez-vous des points importants suivants :
La réplication logique d’un grand nombre de tables n’a pas obligatoirement besoin d’un grand nombre d’expéditeurs de journal WAL.
La seule raison qui vous oblige à séparer l’expéditeur de journal WAL par table ou groupe de tables est si vous avez besoin de séparer les abonnements pour chacune de ces tables ou chacun de ces groupes.
Quel que soit le nombre d’expéditeurs de journal WAL utilisés pour une réplication physique et logique, ils deviennent tous actif en même temps, chaque fois qu’un back-end écrit quelque chose sur le journal WAL (write-ahead log). Lorsque cela se produit, tous les expéditeurs de journal WAL affectés à la réplication logique sortent de veille pour :
Décoder tous les nouveaux enregistrements dans le journal WAL,
Filtrer les enregistrements de journal qui ne les intéressent pas,
Répliquer les données pertinentes à chacun d’entre eux.
Les expéditeurs de journal WAL sont semblables aux connexions au sens que, s’ils sont inactifs, leur nombre n’est pas important. Toutefois, s’ils sont actifs, ils entrent en concurrence pour les mêmes ressources et les performances peuvent devenir terriblement mauvaises. Ceci est particulièrement vrai pour les expéditeurs avec une réplication logique, car le décodage logique est plutôt coûteux en matière de processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Ce n’est pas si important pour la réplication physique, car les expéditeurs de journal WAL ne consomment pas de processeur de manière aussi intensive et ils ont tendance à être liés par bande passante réseau en premier.
Par conséquent, il est préférable, en général, de ne pas avoir beaucoup plus d’expéditeurs de journal WAL que de cœurs virtuels.
Il est conseillé d’ajouter de la place pour quelques expéditeurs de journal WAL supplémentaires pour concilier une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent permettre de mieux l’illustrer.
Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
Pour un serveur avec 16 cœurs virtuels, une haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous souhaitez peut-être configurer max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + des compartiments physiques pour les réplicas en lecture (4) + des emplacements logiques (5) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (2) = 13.
Si vous considérez encore que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, veuillez nous contacter, décrire votre scénario en détail et expliquer ce que vous considérez comme la valeur minimale acceptable dont vous auriez besoin pour que votre scénario fonctionne correctement.
La valeur par défaut du paramètre de serveur max_wal_senders, définie lorsque vous approvisionnez l’instance Azure Database pour PostgreSQL – Serveur flexible, ne doit jamais être diminuée en dessous de 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez la nécessité d’augmenter max_wal_senders vers une valeur beaucoup plus élevé pour pouvoir faire face à la réplication logique d’un nombre considérable de tables, rappelez-vous des points importants suivants :
La réplication logique d’un grand nombre de tables n’a pas obligatoirement besoin d’un grand nombre d’expéditeurs de journal WAL.
La seule raison qui vous oblige à séparer l’expéditeur de journal WAL par table ou groupe de tables est si vous avez besoin de séparer les abonnements pour chacune de ces tables ou chacun de ces groupes.
Quel que soit le nombre d’expéditeurs de journal WAL utilisés pour une réplication physique et logique, ils deviennent tous actif en même temps, chaque fois qu’un back-end écrit quelque chose sur le journal WAL (write-ahead log). Lorsque cela se produit, tous les expéditeurs de journal WAL affectés à la réplication logique sortent de veille pour :
Décoder tous les nouveaux enregistrements dans le journal WAL,
Filtrer les enregistrements de journal qui ne les intéressent pas,
Répliquer les données pertinentes à chacun d’entre eux.
Les expéditeurs de journal WAL sont semblables aux connexions au sens que, s’ils sont inactifs, leur nombre n’est pas important. Toutefois, s’ils sont actifs, ils entrent en concurrence pour les mêmes ressources et les performances peuvent devenir terriblement mauvaises. Ceci est particulièrement vrai pour les expéditeurs avec une réplication logique, car le décodage logique est plutôt coûteux en matière de processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Ce n’est pas si important pour la réplication physique, car les expéditeurs de journal WAL ne consomment pas de processeur de manière aussi intensive et ils ont tendance à être liés par bande passante réseau en premier.
Par conséquent, il est préférable, en général, de ne pas avoir beaucoup plus d’expéditeurs de journal WAL que de cœurs virtuels.
Il est conseillé d’ajouter de la place pour quelques expéditeurs de journal WAL supplémentaires pour concilier une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent permettre de mieux l’illustrer.
Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
Pour un serveur avec 16 cœurs virtuels, une haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous souhaitez peut-être configurer max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + des compartiments physiques pour les réplicas en lecture (4) + des emplacements logiques (5) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (2) = 13.
Si vous considérez encore que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, veuillez nous contacter, décrire votre scénario en détail et expliquer ce que vous considérez comme la valeur minimale acceptable dont vous auriez besoin pour que votre scénario fonctionne correctement.
La valeur par défaut du paramètre de serveur max_wal_senders, définie lorsque vous approvisionnez l’instance Azure Database pour PostgreSQL – Serveur flexible, ne doit jamais être diminuée en dessous de 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez la nécessité d’augmenter max_wal_senders vers une valeur beaucoup plus élevé pour pouvoir faire face à la réplication logique d’un nombre considérable de tables, rappelez-vous des points importants suivants :
La réplication logique d’un grand nombre de tables n’a pas obligatoirement besoin d’un grand nombre d’expéditeurs de journal WAL.
La seule raison qui vous oblige à séparer l’expéditeur de journal WAL par table ou groupe de tables est si vous avez besoin de séparer les abonnements pour chacune de ces tables ou chacun de ces groupes.
Quel que soit le nombre d’expéditeurs de journal WAL utilisés pour une réplication physique et logique, ils deviennent tous actif en même temps, chaque fois qu’un back-end écrit quelque chose sur le journal WAL (write-ahead log). Lorsque cela se produit, tous les expéditeurs de journal WAL affectés à la réplication logique sortent de veille pour :
Décoder tous les nouveaux enregistrements dans le journal WAL,
Filtrer les enregistrements de journal qui ne les intéressent pas,
Répliquer les données pertinentes à chacun d’entre eux.
Les expéditeurs de journal WAL sont semblables aux connexions au sens que, s’ils sont inactifs, leur nombre n’est pas important. Toutefois, s’ils sont actifs, ils entrent en concurrence pour les mêmes ressources et les performances peuvent devenir terriblement mauvaises. Ceci est particulièrement vrai pour les expéditeurs avec une réplication logique, car le décodage logique est plutôt coûteux en matière de processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Ce n’est pas si important pour la réplication physique, car les expéditeurs de journal WAL ne consomment pas de processeur de manière aussi intensive et ils ont tendance à être liés par bande passante réseau en premier.
Par conséquent, il est préférable, en général, de ne pas avoir beaucoup plus d’expéditeurs de journal WAL que de cœurs virtuels.
Il est conseillé d’ajouter de la place pour quelques expéditeurs de journal WAL supplémentaires pour concilier une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent permettre de mieux l’illustrer.
Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
Pour un serveur avec 16 cœurs virtuels, une haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous souhaitez peut-être configurer max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + des compartiments physiques pour les réplicas en lecture (4) + des emplacements logiques (5) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (2) = 13.
Si vous considérez encore que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, veuillez nous contacter, décrire votre scénario en détail et expliquer ce que vous considérez comme la valeur minimale acceptable dont vous auriez besoin pour que votre scénario fonctionne correctement.
La valeur par défaut du paramètre de serveur max_wal_senders, définie lorsque vous approvisionnez l’instance Azure Database pour PostgreSQL – Serveur flexible, ne doit jamais être diminuée en dessous de 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez la nécessité d’augmenter max_wal_senders vers une valeur beaucoup plus élevé pour pouvoir faire face à la réplication logique d’un nombre considérable de tables, rappelez-vous des points importants suivants :
La réplication logique d’un grand nombre de tables n’a pas obligatoirement besoin d’un grand nombre d’expéditeurs de journal WAL.
La seule raison qui vous oblige à séparer l’expéditeur de journal WAL par table ou groupe de tables est si vous avez besoin de séparer les abonnements pour chacune de ces tables ou chacun de ces groupes.
Quel que soit le nombre d’expéditeurs de journal WAL utilisés pour une réplication physique et logique, ils deviennent tous actif en même temps, chaque fois qu’un back-end écrit quelque chose sur le journal WAL (write-ahead log). Lorsque cela se produit, tous les expéditeurs de journal WAL affectés à la réplication logique sortent de veille pour :
Décoder tous les nouveaux enregistrements dans le journal WAL,
Filtrer les enregistrements de journal qui ne les intéressent pas,
Répliquer les données pertinentes à chacun d’entre eux.
Les expéditeurs de journal WAL sont semblables aux connexions au sens que, s’ils sont inactifs, leur nombre n’est pas important. Toutefois, s’ils sont actifs, ils entrent en concurrence pour les mêmes ressources et les performances peuvent devenir terriblement mauvaises. Ceci est particulièrement vrai pour les expéditeurs avec une réplication logique, car le décodage logique est plutôt coûteux en matière de processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Ce n’est pas si important pour la réplication physique, car les expéditeurs de journal WAL ne consomment pas de processeur de manière aussi intensive et ils ont tendance à être liés par bande passante réseau en premier.
Par conséquent, il est préférable, en général, de ne pas avoir beaucoup plus d’expéditeurs de journal WAL que de cœurs virtuels.
Il est conseillé d’ajouter de la place pour quelques expéditeurs de journal WAL supplémentaires pour concilier une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent permettre de mieux l’illustrer.
Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
Pour un serveur avec 16 cœurs virtuels, une haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous souhaitez peut-être configurer max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + des compartiments physiques pour les réplicas en lecture (4) + des emplacements logiques (5) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (2) = 13.
Si vous considérez encore que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, veuillez nous contacter, décrire votre scénario en détail et expliquer ce que vous considérez comme la valeur minimale acceptable dont vous auriez besoin pour que votre scénario fonctionne correctement.
La valeur par défaut du paramètre de serveur max_wal_senders, définie lorsque vous approvisionnez l’instance Azure Database pour PostgreSQL – Serveur flexible, ne doit jamais être diminuée en dessous de 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez la nécessité d’augmenter max_wal_senders vers une valeur beaucoup plus élevé pour pouvoir faire face à la réplication logique d’un nombre considérable de tables, rappelez-vous des points importants suivants :
La réplication logique d’un grand nombre de tables n’a pas obligatoirement besoin d’un grand nombre d’expéditeurs de journal WAL.
La seule raison qui vous oblige à séparer l’expéditeur de journal WAL par table ou groupe de tables est si vous avez besoin de séparer les abonnements pour chacune de ces tables ou chacun de ces groupes.
Quel que soit le nombre d’expéditeurs de journal WAL utilisés pour une réplication physique et logique, ils deviennent tous actif en même temps, chaque fois qu’un back-end écrit quelque chose sur le journal WAL (write-ahead log). Lorsque cela se produit, tous les expéditeurs de journal WAL affectés à la réplication logique sortent de veille pour :
Décoder tous les nouveaux enregistrements dans le journal WAL,
Filtrer les enregistrements de journal qui ne les intéressent pas,
Répliquer les données pertinentes à chacun d’entre eux.
Les expéditeurs de journal WAL sont semblables aux connexions au sens que, s’ils sont inactifs, leur nombre n’est pas important. Toutefois, s’ils sont actifs, ils entrent en concurrence pour les mêmes ressources et les performances peuvent devenir terriblement mauvaises. Ceci est particulièrement vrai pour les expéditeurs avec une réplication logique, car le décodage logique est plutôt coûteux en matière de processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Ce n’est pas si important pour la réplication physique, car les expéditeurs de journal WAL ne consomment pas de processeur de manière aussi intensive et ils ont tendance à être liés par bande passante réseau en premier.
Par conséquent, il est préférable, en général, de ne pas avoir beaucoup plus d’expéditeurs de journal WAL que de cœurs virtuels.
Il est conseillé d’ajouter de la place pour quelques expéditeurs de journal WAL supplémentaires pour concilier une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent permettre de mieux l’illustrer.
Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
Pour un serveur avec 16 cœurs virtuels, une haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous souhaitez peut-être configurer max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + des compartiments physiques pour les réplicas en lecture (4) + des emplacements logiques (5) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (2) = 13.
Si vous considérez encore que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, veuillez nous contacter, décrire votre scénario en détail et expliquer ce que vous considérez comme la valeur minimale acceptable dont vous auriez besoin pour que votre scénario fonctionne correctement.
La valeur par défaut du paramètre de serveur max_wal_senders, définie lorsque vous approvisionnez l’instance Azure Database pour PostgreSQL – Serveur flexible, ne doit jamais être diminuée en dessous de 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez la nécessité d’augmenter max_wal_senders vers une valeur beaucoup plus élevé pour pouvoir faire face à la réplication logique d’un nombre considérable de tables, rappelez-vous des points importants suivants :
La réplication logique d’un grand nombre de tables n’a pas obligatoirement besoin d’un grand nombre d’expéditeurs de journal WAL.
La seule raison qui vous oblige à séparer l’expéditeur de journal WAL par table ou groupe de tables est si vous avez besoin de séparer les abonnements pour chacune de ces tables ou chacun de ces groupes.
Quel que soit le nombre d’expéditeurs de journal WAL utilisés pour une réplication physique et logique, ils deviennent tous actif en même temps, chaque fois qu’un back-end écrit quelque chose sur le journal WAL (write-ahead log). Lorsque cela se produit, tous les expéditeurs de journal WAL affectés à la réplication logique sortent de veille pour :
Décoder tous les nouveaux enregistrements dans le journal WAL,
Filtrer les enregistrements de journal qui ne les intéressent pas,
Répliquer les données pertinentes à chacun d’entre eux.
Les expéditeurs de journal WAL sont semblables aux connexions au sens que, s’ils sont inactifs, leur nombre n’est pas important. Toutefois, s’ils sont actifs, ils entrent en concurrence pour les mêmes ressources et les performances peuvent devenir terriblement mauvaises. Ceci est particulièrement vrai pour les expéditeurs avec une réplication logique, car le décodage logique est plutôt coûteux en matière de processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Ce n’est pas si important pour la réplication physique, car les expéditeurs de journal WAL ne consomment pas de processeur de manière aussi intensive et ils ont tendance à être liés par bande passante réseau en premier.
Par conséquent, il est préférable, en général, de ne pas avoir beaucoup plus d’expéditeurs de journal WAL que de cœurs virtuels.
Il est conseillé d’ajouter de la place pour quelques expéditeurs de journal WAL supplémentaires pour concilier une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent permettre de mieux l’illustrer.
Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
Pour un serveur avec 16 cœurs virtuels, une haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous souhaitez peut-être configurer max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + des compartiments physiques pour les réplicas en lecture (4) + des emplacements logiques (5) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (2) = 13.
Si vous considérez encore que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, veuillez nous contacter, décrire votre scénario en détail et expliquer ce que vous considérez comme la valeur minimale acceptable dont vous auriez besoin pour que votre scénario fonctionne correctement.
La valeur par défaut du paramètre de serveur max_wal_senders, définie lorsque vous approvisionnez l’instance Azure Database pour PostgreSQL – Serveur flexible, ne doit jamais être diminuée en dessous de 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez la nécessité d’augmenter max_wal_senders vers une valeur beaucoup plus élevé pour pouvoir faire face à la réplication logique d’un nombre considérable de tables, rappelez-vous des points importants suivants :
La réplication logique d’un grand nombre de tables n’a pas obligatoirement besoin d’un grand nombre d’expéditeurs de journal WAL.
La seule raison qui vous oblige à séparer l’expéditeur de journal WAL par table ou groupe de tables est si vous avez besoin de séparer les abonnements pour chacune de ces tables ou chacun de ces groupes.
Quel que soit le nombre d’expéditeurs de journal WAL utilisés pour une réplication physique et logique, ils deviennent tous actif en même temps, chaque fois qu’un back-end écrit quelque chose sur le journal WAL (write-ahead log). Lorsque cela se produit, tous les expéditeurs de journal WAL affectés à la réplication logique sortent de veille pour :
Décoder tous les nouveaux enregistrements dans le journal WAL,
Filtrer les enregistrements de journal qui ne les intéressent pas,
Répliquer les données pertinentes à chacun d’entre eux.
Les expéditeurs de journal WAL sont semblables aux connexions au sens que, s’ils sont inactifs, leur nombre n’est pas important. Toutefois, s’ils sont actifs, ils entrent en concurrence pour les mêmes ressources et les performances peuvent devenir terriblement mauvaises. Ceci est particulièrement vrai pour les expéditeurs avec une réplication logique, car le décodage logique est plutôt coûteux en matière de processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Ce n’est pas si important pour la réplication physique, car les expéditeurs de journal WAL ne consomment pas de processeur de manière aussi intensive et ils ont tendance à être liés par bande passante réseau en premier.
Par conséquent, il est préférable, en général, de ne pas avoir beaucoup plus d’expéditeurs de journal WAL que de cœurs virtuels.
Il est conseillé d’ajouter de la place pour quelques expéditeurs de journal WAL supplémentaires pour concilier une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent permettre de mieux l’illustrer.
Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
Pour un serveur avec 16 cœurs virtuels, une haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous souhaitez peut-être configurer max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + des compartiments physiques pour les réplicas en lecture (4) + des emplacements logiques (5) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (2) = 13.
Si vous considérez encore que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, veuillez nous contacter, décrire votre scénario en détail et expliquer ce que vous considérez comme la valeur minimale acceptable dont vous auriez besoin pour que votre scénario fonctionne correctement.