On Fri, Sep 26, 2014 at 12:32 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> 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.
>
> I don't think that's a very meaningful comparison. The problem with
> infomask bits is that it's impossible to change anything once added
> because of pg_upgrade'ability. That problem does not exist for
> XLogRecord. We've twiddled with the WAL format pretty much in every
> release. We can reconsider every release.
>
> I can't remember anyone but me thinking about using these two bytes. So
> the comparison here really is using two free bytes vs. issuing at least
> ~30 (record + origin) for every replayed transaction. Don't think that's
> a unfair tradeof.
Mmph. You have a point about the WAL format being easier to change.
"Reconsidering", though, would mean that some developer who probably
isn't you needs those bytes for something that really is a more
general need than this, so they write a patch to get them back by
doing what I proposed - and then it gets rejected because it's not as
good for logical replication. So I'm not sure I really buy this as an
argument. For all practical purposes, if you grab them, they'll be
gone.
>> > 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.
>
> Ah. I thought you only wanted to suggest a separator between the
> replication solution and it's internal dat. But you actually want to
> suggest an internal separator to be used in the solution's namespace?
> I'm fine with that. I don't think we can suggest much beyond that -
> different solutions will have fundamentally differing requirements about
> which information to store.
Agreed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company