From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Steve Singer <steve(at)ssinger(dot)info> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, 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-29 14:59:20 |
Message-ID: | CA+TgmoYgEALOrWajg9vhx9ymxh8ykkKm5svD3d_sdvwO-DrBmg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Sep 27, 2014 at 12:11 PM, Steve Singer <steve(at)ssinger(dot)info> wrote:
> 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?
Obviously not. Otherwise Andres would be proposing to put an OID in
there instead of a kooky 16-bit 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,
I lean in that direction too, but would welcome more input from others.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2014-09-29 15:00:26 | Re: Yet another abort-early plan disaster on 9.3 |
Previous Message | Stephen Frost | 2014-09-29 14:45:24 | Re: json (b) and null fields |