Alvaro Herrera writes:
> Excerpts from Tom Lane's message of sáb jul 31 09:57:13 -0400 2010:
>> So far as I can see, it's impossible to handle this situation when
>> examining only one TID per stream with no lookahead. Choosing to
>> advance the second stream would obviously fail in many other c
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of sáb jul 31 09:57:13 -0400 2010:
>> So far as I can see, it's impossible to handle this situation when
>> examining only one TID per stream with no lookahead. Choosing to
>> advance the second stream would obviously fail in many other c
Excerpts from Tom Lane's message of sáb jul 31 09:57:13 -0400 2010:
> So far as I can see, it's impossible to handle this situation when
> examining only one TID per stream with no lookahead. Choosing to
> advance the second stream would obviously fail in many other cases,
> so there is no correc
I fixed the problem I was on about earlier with ginget.c doing the wrong
thing for keystreams like this:
... ...
42/642/65535
42/7...
...
(To recap, after reporting the potential lossy match for 42/6, the
previous code would adva
