| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> | 
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: WIP partial replication patch | 
| Date: | 2010-08-13 22:02:16 | 
| Message-ID: | 22873.1281736936@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> Another rather basic problem is that you've
>> got to pass system catalog updates downstream (in case they affect
>> the tables being replicated) but if you want partial replication then
>> many of those updates will be incorrect for the slave machine.
> Couldn't this be taken care of by replicating the objects but not any
> data for them?  That is, the tables and indexes would exist, but be empty?
Seems a bit pointless.  What exactly is the use-case for a slave whose
system catalogs match the master exactly (as they must) but whose data
does not?
Notice also that you have to shove the entire WAL downstream anyway ---
the proposed patch filters at the point of application, and would have a
hard time doing better because LSNs have to remain consistent.
It would also be rather tricky to identify which objects have to have
updates applied, eg, if you replicate a table you'd damn well better
replicate the data for each and every one of its indexes (which is a
non-constant set in general), because queries on the slave will expect
them all to be valid.  Maybe it's possible to keep track of that, though
I bet things will be tricky when there are uncommitted DDL changes
(consider data changes associated with a CREATE INDEX on a replicated
table).  In any case xlog replay functions are not the place to have
that kind of logic.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-08-13 22:14:10 | Re: Window functions seem to inhibit push-down of quals into views | 
| Previous Message | Tom Lane | 2010-08-13 21:51:08 | Re: pgsql: Include the backend ID in the relpath of temporary relations. |