On Fri, Sep 26, 2014 at 10:55 AM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2014-09-26 10:40:37 -0400, Robert Haas wrote: >> 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 don't think that's a fair characterization. Right now it's available > to precisely nobody. You can't put any data in there in *any* way. It > just has been sitting around unused for at least 8 years.
Huh? That's just to say that the unused bit space is, in fact, unused. But so what? We've always been very careful about using up things like infomask bits, because there are only so many bits available, and when they're gone they are gone. >> 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. > > I've also wondered about that. Perhaps we simply should have an > additional 'name' column indicating the replication solution? Yeah, maybe, but there's still the question of substructure within the non-replication-solution part of the name. Not sure if we can assume that a bipartite identifier, specifically, is right, or whether some solutions will end up with different numbers of components. -- 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
