On Fri, Sep 26, 2014 at 10:21 AM, Andres Freund <and...@2ndquadrant.com> wrote: > As explained above this isn't happening on the level of individual AMs.
Well, that's even worse. You want to grab 100% of the available generic bitspace applicable to all record types for purposes specific to logical decoding (and it's still not really enough bits). >> I get that, but what I'm asking is why those mappings can't be managed >> on a per-replication-solution basis. I think that's just because >> there's a limited namespace and so coordination is needed between >> multiple replication solutions that might possibly be running on the >> same system. But I want to confirm if that's actually what you're >> thinking. > > Yes, that and that such a mapping needs to be done across all database > are the primary reasons. As it's currently impossible to create further > shared relations you'd have to invent something living in the data > directory on filesystem level... Brr. > > I think it'd also be much worse for debugging if there'd be no way to > map such a internal identifier back to the replication solution in some > form. OK. One question I have is what the structure of the names should be. It seems some coordination could be needed here. I mean, suppose BDR uses bdr:$NODENAME and Slony uses $SLONY_CLUSTER_NAME:$SLONY_INSTANCE_NAME and EDB's xDB replication server uses xdb__$NODE_NAME. That seems like it would be sad. Maybe we should decide that names ought to be of the form <replication-solution>.<further-period-separated-components> or something like that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
