Thread: BUG: Protocol 3.0 ErrorResponse: Last 'null' character seems odd
53 46 41 54 41 4C 00 43 30 38 50 30 31 00 4D 69 SFATAL.C08P01.Mi 6E 76 61 6C 69 64 20 73 74 61 72 74 75 70 20 70 nvalid.startup.p 61 63 6B 65 74 20 6C 61 79 6F 75 74 3A 20 65 78 acket.layout:.ex 70 65 63 74 65 64 20 74 65 72 6D 69 6E 61 74 6F pected.terminato 72 20 61 73 20 6C 61 73 74 20 62 79 74 65 00 46 r.as.last.byte.F 2E 5C 73 72 63 5C 62 61 63 6B 65 6E 64 5C 70 6F .\src\backend\po 73 74 6D 61 73 74 65 72 5C 70 6F 73 74 6D 61 73 stmaster\postmas 74 65 72 2E 63 00 4C 31 35 35 37 00 52 50 72 6F ter.c.L1557.RPro 63 65 73 73 53 74 61 72 74 75 70 50 61 63 6B 65 cessStartupPacke 74 00 00 t.. Last 'null' character seems odd=
Eugen.Konkov@aldec.com wrote: > 53 46 41 54 41 4C 00 43 30 38 50 30 31 00 4D 69 SFATAL.C08P01.Mi > 6E 76 61 6C 69 64 20 73 74 61 72 74 75 70 20 70 nvalid.startup.p > 61 63 6B 65 74 20 6C 61 79 6F 75 74 3A 20 65 78 acket.layout:.ex > 70 65 63 74 65 64 20 74 65 72 6D 69 6E 61 74 6F pected.terminato > 72 20 61 73 20 6C 61 73 74 20 62 79 74 65 00 46 r.as.last.byte.F > 2E 5C 73 72 63 5C 62 61 63 6B 65 6E 64 5C 70 6F .\src\backend\po > 73 74 6D 61 73 74 65 72 5C 70 6F 73 74 6D 61 73 stmaster\postmas > 74 65 72 2E 63 00 4C 31 35 35 37 00 52 50 72 6F ter.c.L1557.RPro > 63 65 73 73 53 74 61 72 74 75 70 50 61 63 6B 65 cessStartupPacke > 74 00 00 t.. > > Last 'null' character seems odd It's part of the protocol, actually (yes, two NUL bytes -- first one signals the end of the previous string, the second one signals the end of the packet). -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
> It's part of the protocol, actually (yes, two NUL bytes -- first one > signals the end of the previous string, the second one signals the end > of the packet). The end of the packet can be obtained by packet length ----- Original Message ----- From: "Alvaro Herrera" <alvherre@commandprompt.com> To: <Eugen.Konkov@aldec.com> Cc: <pgsql-bugs@postgresql.org> Sent: Wednesday, April 16, 2008 5:27 PM Subject: Re: [BUGS] BUG: Protocol 3.0 ErrorResponse: Last 'null' characterseems odd > Eugen.Konkov@aldec.com wrote: >> 53 46 41 54 41 4C 00 43 30 38 50 30 31 00 4D 69 SFATAL.C08P01.Mi >> 6E 76 61 6C 69 64 20 73 74 61 72 74 75 70 20 70 nvalid.startup.p >> 61 63 6B 65 74 20 6C 61 79 6F 75 74 3A 20 65 78 acket.layout:.ex >> 70 65 63 74 65 64 20 74 65 72 6D 69 6E 61 74 6F pected.terminato >> 72 20 61 73 20 6C 61 73 74 20 62 79 74 65 00 46 r.as.last.byte.F >> 2E 5C 73 72 63 5C 62 61 63 6B 65 6E 64 5C 70 6F .\src\backend\po >> 73 74 6D 61 73 74 65 72 5C 70 6F 73 74 6D 61 73 stmaster\postmas >> 74 65 72 2E 63 00 4C 31 35 35 37 00 52 50 72 6F ter.c.L1557.RPro >> 63 65 73 73 53 74 61 72 74 75 70 50 61 63 6B 65 cessStartupPacke >> 74 00 00 t.. >> >> Last 'null' character seems odd > > It's part of the protocol, actually (yes, two NUL bytes -- first one > signals the end of the previous string, the second one signals the end > of the packet). > > -- > Alvaro Herrera > http://www.CommandPrompt.com/ > The PostgreSQL Company - Command Prompt, Inc.
<Eugen.Konkov@aldec.com> writes:
>> It's part of the protocol, actually (yes, two NUL bytes -- first one
>> signals the end of the previous string, the second one signals the end
>> of the packet).
> The end of the packet can be obtained by packet length
It's designed that way intentionally to aid in error detection. Parsing
the packet following its internal structure should end up exactly at the
end of the packet according to the length word. Otherwise something's
corrupted.
There are some backwards-compatibility considerations here too (the
internal structure matches pre-V3 protocol which had no length word).
But it's a perfectly fine definition and we have absolutely no intention
of "fixing" it.
regards, tom lane
> It's designed that way intentionally to aid in error detection. Parsing > the packet following its internal structure should end up exactly at the > end of the packet according to the length word. Otherwise something's > corrupted. Why you do not follow this rule for all messages? 70 00 00 00 27 6D 64 35 63 32 36 35 31 31 65 31 p...'md5c26511e1 31 39 65 39 33 62 30 32 35 32 64 32 39 31 38 31 19e93b0252d29181 64 34 38 61 64 37 66 62 d48ad7fb 53 00 00 00 1C 63 6C 69 65 6E 74 5F 65 6E 63 6F S... client_enco 64 69 6E 67 00 57 49 4E 31 32 35 31 00 ding.WIN1251. ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: <Eugen.Konkov@aldec.com> Cc: "Alvaro Herrera" <alvherre@commandprompt.com>; <pgsql-bugs@postgresql.org> Sent: Wednesday, April 16, 2008 6:34 PM Subject: Re: [BUGS] BUG: Protocol 3.0 ErrorResponse: Last 'null' characterseems odd > <Eugen.Konkov@aldec.com> writes: >>> It's part of the protocol, actually (yes, two NUL bytes -- first one >>> signals the end of the previous string, the second one signals the end >>> of the packet). > >> The end of the packet can be obtained by packet length > > It's designed that way intentionally to aid in error detection. Parsing > the packet following its internal structure should end up exactly at the > end of the packet according to the length word. Otherwise something's > corrupted. > > There are some backwards-compatibility considerations here too (the > internal structure matches pre-V3 protocol which had no length word). > But it's a perfectly fine definition and we have absolutely no intention > of "fixing" it. > > regards, tom lane