From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | james(at)mansionfamily(dot)plus(dot)com |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fake async rep target |
Date: | 2012-05-29 23:36:24 |
Message-ID: | 4FC55D78.9030801@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 could convert 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 the way 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 probably a lot cheaper to execute. The key, I think, is to be able to allow dynamic attachment of such a 'change feed' by an 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 anything similar; what is sent is in a completely proprietary, internal-use-only format. Unless that changes (which there has been some discussion of) I doubt such a connection would be of any value.
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2012-05-29 23:41:21 | Re: FDW / list of needed columns, WHERE conditions (in PlanForeignScan) |
Previous Message | Tom Lane | 2012-05-29 23:06:51 | Re: pg_upgrade libraries check |