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.bartol...@2ndquadrant.it | www.2ndQuadrant.it
0001-pg_receivexlog-does-not-report-flush-position-with-s.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
