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.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

> 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.


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

<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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

> 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


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs