On Thu, 11 Jun 2020 at 15:07, Shay Rojansky <r...@roji.org> wrote: > > > Second, across the protocol docs, rather than using Int32 and Int64, >> which >> > generally look like they're signed (depending on which language you're >> > coming from), I'd consider using UInt32/UInt64, which are unambiguous >> with >> > regards to signed-ness. >> >> Well, they are actually signed, so I'm confused why you think we should >> change the documentation to unsigned. >> > > Interesting... I'm not 100% sure, but I recently received a report that > the WAL coordinates in XLogData ( > https://www.postgresql.org/docs/current/protocol-replication.html) are > unsigned longs, is that a mistake? Are you saying all values in the > protocol are always signed? >
AFAICS, the definition is correct. Int64 means an 64-bit integer in network byte order [1]. It does not mention signedness. All LSNs in the protocol messages are advertised as Int64. A possible improvement is to inform that that Int64 is a XLogRecPtr in each message block that contains LSN. It used to be like that before the commit add6c3179a4d4fa3e62dd3e86a00f23303336bac - The starting point of the WAL data in this message, given in - XLogRecPtr format. + The starting point of the WAL data in this message. but it was removed for an unknown reason. [1] https://www.postgresql.org/docs/current/protocol-message-types.html -- Euler Taveira http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
