Brett Okken

@stevenliang16, I can think of no way to move time around. I do not believe that you need to simulate a "network partition", you simply need to make a read...

I agree the read timeout should be easy. The login is more difficult. I cannot think of a consistent/reliable way to cause login to take an arbitrary amount of time....

+1 On Fri, Aug 9, 2019 at 3:58 PM Dave Cramer wrote: > @bokken figured out how to test it. > https://www.postgresql.org/docs/current/runtime-config-developer.html > --pre_auth_delay=10 works! > > — > You...

This was also discussed in some length in https://github.com/pgjdbc/pgjdbc/issues/1048, https://github.com/pgjdbc/pgjdbc/pull/992, and https://github.com/pgjdbc/pgjdbc/pull/1049.

i will update to reflect the changes that @vlsi recently made.

I have updated to match code in trunk. I have also updated the tests for current handling of special 24:00 value in trunk. There are multiple tests failing, with causes...

@davecramer, all 3 are showing an inconsistency between the handling of binary and textual representations. In the case of testLocalTimeMax, both ways fail, but text is failing in an assertion/comparison...

We need a clear definition of what the desired behavior is for the following conditions: 24:00:00 in the database: How should this be presented as a java.sql.Time? How should this...

@davecramer it certainly furthers the talking points. I do not think it gets us to implementable conclusions.

To add to @vlsi's comments, it becomes an interesting trade-off to make the code more difficult to reason about in order to improve the performance primarily for sub-optimal consumers.