From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Steve Singer <steve(at)ssinger(dot)info>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Replication identifiers, take 3 |
Date: | 2014-09-26 18:57:12 |
Message-ID: | CA+TgmoapkG7mT=7VdFD3Az8dHQpQdRi2d7Q6=edjprPAnWBbgQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 26, 2014 at 12:32 PM, Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Smith | 2014-09-26 19:03:34 | Re: proposal: rounding up time value less than its unit. |
Previous Message | Gregory Smith | 2014-09-26 18:52:50 | Re: proposal: rounding up time value less than its unit. |