Re: Fake async rep target - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Fake async rep target
Date
Msg-id 4FC55D78.9030801@nasby.net
Whole thread Raw
In response to Fake async rep target  (james <james@mansionfamily.plus.com>)
Responses Re: Fake async rep target
Re: Fake async rep target
List pgsql-hackers
On 5/29/12 2:46 PM, james wrote:
> How easy would it be to implement a fake async rep target?
>
> Perhaps even as something that a server could allow a connection to request? (ie a suitably permissioned connection
couldconvert itself to receive n async replication stream, rather than being statically configured?)
 
>
> I know that it sounds a bit bonkers, but a while back I worked on a system where we configured a rep target (using
OpenServer)we could observe changes to tables and enqueue secondary processing. Rather painful in that case because of
theway that repserver is configured,
 
> and I'm not sure it was worth the pain when configuring test and dev environments.
>
> However, in principle, it seems that this is quite an elegant standing for a whole raft of trigger functions - and
probablya lot cheaper to execute. The key, I think, is to be able to allow dynamic attachment of such a 'change feed'
byan account that has god-like read access.
 
>
> Is the existing async rep code amenable to this sort of abuse?

How would a client actually use the *binary* information it was handed? There is no ability to turn it into SQL or
anythingsimilar; what is sent is in a completely proprietary, internal-use-only format. Unless that changes (which
therehas been some discussion of) I doubt such a connection would be of any value.
 
-- 
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_upgrade libraries check
Next
From: Tomas Vondra
Date:
Subject: Re: FDW / list of needed columns, WHERE conditions (in PlanForeignScan)