Non, c'est un peu plus compliqué que ça. Quand on fait un update sous PostgreSQL, on n'écrase pas l'enregistrement, on en fait une autre version dans la même table. Donc on a les deux versions simultanément, et les ordres SQL choisissent ce qu'ils veulent. Cette seconde version est répliquée, pas de problème. C'est les VACUUM qui posent problème, puisqu'ils veulent supprimer les vieilles versions d'enregistrement, qui ne sont plus nécessaires sur le primaire. Le hot_standby_feedback permet justement aux standby de prévenir le maître des enregistrement dont ils ont encore besoin.

Tant que j'y pense, vérifiez aussi pg_is_wal_replay_paused() sur le standby quand ça se produit… sait on jamais, un développeur retors

Ça peut., ça dépend de votre paramétrage:
- est-ce que le standby a hot_standby_feedback activé ? (sinon le primaire va supprimer des enregistrements lors de vacuum qui pourraient encore être nécessaires au standby... et donc le standby va devoir arrêter la réplication le temps que ces requetes se terminent)
- que vaut max_standby_streaming_delay ? c'est le temps maximum que le standby va accepter d'attendre avant de commencer à tuer les requêtes qui bloquent la réapplication des journaux

Ok, donc effectivement, c'est la voie à suivre. Et oui, il vous faudra un script de purge des journaux

Bonjour, quand on crée une contrainte, on peut lui dire ‹on delete cascade›. Je pense que c'est ce que vous cherchez.

le recovery.conf est renommé en recovery.done à la fin de la restauration (donc pour une streaming replication, au moment du promote du serveur)

C'est plus simple, je trouve, avec la syntaxe ARRAY[], dans ce cas là:

ARRAY[X'00000001', X'00000002', X'00000004'];

Sinon vous pouvez initialiser la variable avec une fonction, par exemple:

create or replace function genere_array () returns int[] language plpgsql as
$$
declare i int;
declare ctableau int[]:= array[]::int[];
begin
  for i in 0..31 loop
          ctableau := ctableau || (1<<i);
  end loop;
  return ctableau;
end
$$
;

On peut facilement s'en sortir avec integer ou bit, vu qu'on a des opérateurs de cast...

Par exemple:

=> select (12::bit(32) & 27::bit(32))::integer;
 int4 
------
    8
(1 row)

Integer sera plus compact (ça n'est pas un type de taille variable, donc on ne perd pas de place sur l'entête).

Par contre, c'est probablement pas très très conforme à la première forme normale (atomicité des attributs), même si c'est difficile de l'affirmer sans le schéma...

Vous n'y arriverez pas en SQL pur, ni avec PLPgSQL, si vous avez un nombre dynamique de colonnes. Ou alors il faudra passer par des manipulations qui vont vous ruiner les perfs je pense.

À mon avis c'est beaucoup plus simple si vous utilisez un des langages de procédures stockées un peu plus dynamiques… plpython ou plperl par exemple. Un exemple en PLPerl:

create language plperlu;
create table test (a int, b varchar, c varchar);
insert into test values (1,'a','b');

create or replace function demo (test) returns void language plperlu as
$$
  use Data::Dumper;
  my $args=shift;
  print elog(Dumper(INFO,$args)) ;
$$
;

select demo(test) from test;
INFO:  $VAR1 = {
          'a' => '1',
          'c' => 'b',
          'b' => 'a'
        };

 demo 
------

Quelques notes… j'ai utilisé plperlu (untrusted) simplement parce que je voulais utiliser la fonction Dumper, qui permet d'afficher le hash facilement. Ce n'est évidemment pas nécessaire si je veux manipuler les données et enrichir une colonne avec un trigger. Là mon trigger ne fait rien que montrer qu'il a reçu en paramètre l'enregistrement en question… et que mon code se moque totalement du typage de ce paramètre, il s'y adapte dynamiquement.

Bref, il vous faut un langage qui sache recevoir un type dynamique (l'enregistrement) et en analyser la structure au moment de l'exécution. Par exemple, perl avec un hash, python avec un dict...

Bonjour. Cette question concerne enterprisedb, qui est un logiciel propriétaire, pas postgresql. Il faut que vous vous adressiez à leur support.

C'est clairement un problème de RAM. Avec 16Go de RAM, redescendez shared_buffers à 4GB, maintenance_work_mem à 1GB ça devrait passer tout seul. Et oui, c'est l'OOM qui a tué votre processus de restauration

Bonjour,

Votre archivage ne fonctionne pas. Allez regarder dans la log vous devriez y trouver des messages d'erreur