Re: vacuum full et hot standby WAL stream: FATAL

Le 28 mai 2016 à 00:44, Michael Paquier <[email protected]> a écrit
:

> 2016-05-28 2:20 GMT+09:00 Guillaume Lelarge <[email protected]>:
> > Le 27 mai 2016 6:04 PM, "Daniel Verite" <[email protected]> a
> écrit :
> >> Sur le dernier point, non il n'y pas de cohérence systématique,
> >> c'est d'ailleurs une nouveauté de la 9.6 actuellement en beta:
> >> synchronous_commit = 'remote_apply'
> >>
> >> Voir (en anglais):
> >> https://www.postgresql.org/docs/9.6/static/runtime-config-wal.html
> >>
> >> ainsi que:
> >>
> >>
> http://michael.otacoo.com/postgresql-2/postgres-9-6-feature-highlight-remote-apply/
> >>
> >
> > Ce n'est malheureusement pas la seule erreur dans cet article. Dans le
> cas
> > d'une réplication synchrone, même si on a configuré plusieurs serveurs
> > synchrones, le maître n'attend que la réponse du premier (et non pas de
> tous
> > comme je le dis dans l'article).
>
> Avec synchrounous_standby_names = 'N (standby1, standby2 ...
> standbyM)', il me semblait que l'on attendait le message de
> confirmation des N premiers esclaves listés ici. Sinon quel est
> l'intérêt de pouvoir en utiliser plusieurs? On doit être sûr que le
> WAL de la transaction est présente dans ces N esclaves selon
> synchronous_commit bien sûr. Y a-t-il des erreurs dans des
> formulations de cet article?
>

Ah mince, je comprends le problème. Je ne parlais pas de ton article mais
du mien :), dont le lien a été donné plus haut dans la discussion (
http://www.dalibo.org/glmf131_mise_en_place_replication_postgresl_9.0_1),
qui parle de la 9.0. Et je me rend compte en disant cela que, du coup, je
ne couvrais pas la réplication synchrone telle qu'implémentée dans
PostgreSQL, vu que cette dernière n'apparaît qu'en 9.1. Et du coup, c'est
moins gênant comme "erreur". Je vais me coucher un peu mieux ce soir du
coup :-)


-- 
Guillaume.
  http://blog.guillaume.lelarge.info
  http://www.dalibo.com