Alvaro Herrera alvhe...@commandprompt.com 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
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
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 correct
Alvaro Herrera alvhe...@commandprompt.com 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
