Re: Replication identifiers, take 3 - Mailing list pgsql-hackers

On 09/26/2014 06:05 PM, Andres Freund wrote:
> On 2014-09-26 14:57:12 -0400, Robert Haas wrote:
> Sure, it'll possibly not be trivial to move them elsewhere. On the other
> hand, the padding bytes have been unused for 8+ years without somebody
> laying "claim" on them but "me". I don't think it's a good idea to leave
> them there unused when nobody even has proposed another use for a long
> while. That'll just end up with them continuing to be unused.  And
> there's actually four more consecutive bytes on 64bit systems that are
> unused.
>
> Should there really be a dire need after that, we can simply bump the
> record size. WAL volume wise it'd not be too bad to make the record a
> tiny bit bigger - the header is only a relatively small fraction of the
> entire content.

If we were now increasing the WAL record size anyway for some unrelated 
reason, would we be willing to increase it by a further 2 bytes for the 
node identifier?
If the answer is 'no' then I don't think we can justify using the 2 
padding bytes just because they are there and have been unused for 
years.  But if the answer is yes, we feel this important enough to 
justfiy a slightly (2 byte) larger WAL record header then we shouldn't 
use the excuse of maybe needing those 2 bytes for something else.   When 
something else comes along that needs the WAL space we'll have to 
increase the record size.

To say that if some other patch comes along that needs the space we'll 
redo this feature to use the method Robert describes is unrealistic.  If 
we think that the replication identifier  isn't 
general/important/necessary to justify 2 bytes of WAL header space then 
we should start out with something that doesn't use the WAL header,



Steve

>>>>> 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.
> So, let's recommend underscores as that separator?
>
> Greetings,
>
> Andres Freund
>