From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Separation walsender & normal backends |
Date: | 2017-04-26 00:41:46 |
Message-ID: | CAMsr+YGsNG3FgzH5=bz=i4jgBDx0N2E1tfpG4PviTJ+Ft+EB7g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 26 April 2017 at 02:36, Andres Freund <andres(at)anarazel(dot)de> wrote:
> For
> logical rep we'd alternatively add more complexity because we'd need
> both replication and non-replication connections (to stream changes, to
> copy tables, to query config), which'd also complicate administration
> because users & hba config have to be setup so the same user can connect
> over both.
We have experience of this from BDR and pglogical, of course, and it's
definitely a pain and source of user misconfiguration.
I'm not sure how practical it is to merge walsenders and regular
backends at this stage of pg10 development, but it seems like a
worthwhile goal down the track. I'd very much like to reduce the
amount of magic global juggling done by the walsender, unify the
XLogRead paths, unify the timeline following logic for physical
walsenders, logical walsenders and logical decoding on normal
backends, allow normal backends to be signaled when there's new WAL,
etc. I think there's a fair bit to do in order to do this well though.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-04-26 00:46:10 | Re: scram and \password |
Previous Message | Craig Ringer | 2017-04-26 00:36:31 | Re: [PostgreSQL 10] default of hot_standby should be "on"? |