Hi guys,
while adding synchronous WAL streaming to Barman, I noticed that pg_receivexlog - unless a replication slot is specified and --synchronous is passed - does not become a synchronous receiver (if the application_name is in the synchronous_standby_names value). I was a bit surprised by this behaviour.
By reading the pg_receivexlog documentation, I assumed that:
1) if I set application_name properly for pg_receivexlog (let's say 'barman_receive_wal')
2) then I set synchronous_standby_names so that barman_receive_wal is first in the list
3) then I run pg_receivexlog with --synchronous
I would find the pg_receivexlog in 'sync' state in the pg_stat_replication view on the master.
However, I kept receiving the 'async' state. After looking at the documentation once more, I noticed that '--synchronous' was mentioned also in the '--slot-name' option but the explanation - at least to me - was not very clear.
I tried again by creating a replication slot and passing it to pg_receivexlog and this time I could see 'sync' as streaming state.
Looking up the code in more details I see that, unless replication slot are enabled, pg_receivexlog does not report the flush position (this is a precaution that's been taken when '--synchronous' was probably not around). Please find this very short patch which - in case replication slots are not present but synchronous is - reports the flush position.
I am not sure if it is a bug or not. I any case I guess we should probably improve the documentation - it's a bit late here so maybe I can try better tomorrow with a fresher mind. :)
Thanks,
Gabriele
--
Gabriele Bartolini - 2ndQuadrant Italia - Director
PostgreSQL Training, Services and Support
gabriele.bartolini@2ndQuadrant.it |
www.2ndQuadrant.it
