On 5/31/2014 11:47 PM, John R Pierce wrote:
On 5/31/2014 11:41 PM, David Wall wrote:
FATAL: invalid value for parameter "TimeZone": "PST"
I'd be using "America/Los_Angeles" as the timezone rather than PST,
as the TLA timezones are ambiguous (CST is both Central Standard Time
in the USA,
On 6/1/2014 12:16 AM, David Wall wrote:
at
com.esignforms.db.ConnectionPool.makeConnection(ConnectionPool.java:302)
that sounds like some form of connection pool.
perhaps connections are being shared between client processes that
expect different timezones?
--
john r pierce
On 06/01/2014 12:16 AM, David Wall wrote:
On 5/31/2014 11:47 PM, John R Pierce wrote:
On 5/31/2014 11:41 PM, David Wall wrote:
FATAL: invalid value for parameter "TimeZone": "PST"
I'd be using "America/Los_Angeles" as the timezone rather than PST,
as the TLA timezones are ambiguous (CST is
David Wall writes:
> The exception occurs when JDBC tries to connect to PG:
> 2014-05-31 22:14:34,351 ERROR (eSignForms) SQLException:
> ConnectionPool.makeConnection(esf) to URL:
> jdbc:postgresql://localhost.localdomain:25432/zingr:
> 2014-05-31 22:14:34,352 ERROR (eSignForms) Message: FA
On 6/1/2014 9:05 AM, Adrian Klaver wrote:
I ask because a look at the PG JDBC code shows this, which did not
show up until Sept 22, 2011. Not sure what release, but it looks like
9.2+:
// Construct and send a startup packet.
String[][] params = {
On 06/01/2014 11:42 AM, David Wall wrote:
On 6/1/2014 9:05 AM, Adrian Klaver wrote:
The JDBC code above, if I am following correctly, is picking up a
default timezone of 'PST' and then in the first if returning that as
the tz value to SET TimeZone in the startup packet.
Two things.
1) Where
On Thu, May 29, 2014 at 12:58 PM, Sébastien Lorion wrote:
> I have a master database sharded by user_id, with globally unique IDs for
> everything, except shared configuration data stored in global tables
> (resources strings, system parameters, etc).
>
> What would be the best (ie both fast and
On 6/1/2014 12:59 PM, Sébastien Lorion wrote:
it would have been nice to avoid the additional complexity if it had
been possible to merge sharded tables on a binary level (which should
be much faster than statement level), given that their records will
never overlap (i.e. the same record is nev
As your query contains order by on host_id, so it will be sorted only based on
host_id. Since in your case host_id is same for both rows, the order in which
host_name will be selected will be absolutely random.
If you want query to returns rows sorted on host_name also, then you should add
host
