On Fri, Jan 1, 2016 at 11:36 AM, Joshua D. Drake wrote:
> Welcome to 2016.
>
> Let's have another bang up year!
+1.
--
Michael
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Welcome to 2016.
Let's have another bang up year!
--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone els
On 12/31/2015 03:05 PM, gkhan wrote:
Follow-up:
My initial question was about oddly-formatted date/times. The suggested
solution of casting directly to timestamp with ::timestamp is not as
flexible as the to_timestamp function that I was trying to avoid. For
example, this fails because of the
On 12/31/15 5:05 PM, gkhan wrote:
For
example, this fails because of the day-before-month format:
Right, which is why Tom had in his example:
regression=# set datestyle = dmy;
BTW, my recommendation would be to store in a timestamptz field *with
the correct timezone*, and then convert on out
Follow-up:
My initial question was about oddly-formatted date/times. The suggested
solution of casting directly to timestamp with ::timestamp is not as
flexible as the to_timestamp function that I was trying to avoid. For
example, this fails because of the day-before-month format:
SELECT ('18.0
On 12/31/2015 01:34 PM, gkhan wrote:
Thanks very much for both of your replies. I had tried something similar and
gotten an error, so I am probably making a stupid mistake. If I try this,
it works:
SELECT ('09.03.2014'||' '||lpad('3:00:00',8,'0'),'DD.MM.
HH24:MI:SS')::timestamp
but if
Oh sorry, what a dumb mistake! ::timestamp works, of course!
Thanks
--
View this message in context:
http://postgresql.nabble.com/to-timestamp-alternatives-tp5879723p5879746.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing list (
On Thu, Dec 31, 2015 at 2:34 PM, gkhan wrote:
> Thanks very much for both of your replies. I had tried something similar
> and
> gotten an error, so I am probably making a stupid mistake. If I try this,
> it works:
>
>SELECT ('09.03.2014'||' '||lpad('3:00:00',8,'0'),'DD.MM.
> HH24:MI:SS
...I meant to add, "and we therefore try to store all time and date values in
'timestamp without time zone' variables.
--
View this message in context:
http://postgresql.nabble.com/to-timestamp-alternatives-tp5879723p5879739.html
Sent from the PostgreSQL - general mailing list archive at Nabble
Thanks very much for both of your replies. I had tried something similar and
gotten an error, so I am probably making a stupid mistake. If I try this,
it works:
SELECT ('09.03.2014'||' '||lpad('3:00:00',8,'0'),'DD.MM.
HH24:MI:SS')::timestamp
but if I use column names instead of the text,
On 12/31/2015 01:16 PM, George Woodring wrote:
I went and look and we have the ssl_renegotiation_limit set to the
default, which the documentation says is 0.
Well that was the low hanging fruit:)
Given that you see this:
Dec 31 14:04:03 iprobe002 kernel: iPoller2.pl[16044] general protection
I went and look and we have the ssl_renegotiation_limit set to the default,
which the documentation says is 0.
Thanks,
George
iGLASS Networks
www.iglass.net
On Thu, Dec 31, 2015 at 3:16 PM, Adrian Klaver
wrote:
> On 12/31/2015 11:29 AM, George Woodring wrote:
>
>> OS: CentOS 6.6
>> Postgres Ve
gkhan writes:
> Hi. I have a practical need to convert some badly-formatted date/times into
> 'timestamp without time zone' data types. Like other scientists, I try to
> avoid timezone problems by sticking to UTC and using the 'timestamp without
> time zone' data type whenever possible.
> In t
On 12/31/2015 12:30 PM, gkhan wrote:
Hi. I have a practical need to convert some badly-formatted date/times into
'timestamp without time zone' data types. Like other scientists, I try to
avoid timezone problems by sticking to UTC and using the 'timestamp without
time zone' data type whenever pos
Hi. I have a practical need to convert some badly-formatted date/times into
'timestamp without time zone' data types. Like other scientists, I try to
avoid timezone problems by sticking to UTC and using the 'timestamp without
time zone' data type whenever possible.
In this case, I used the to_t
On 12/31/2015 11:29 AM, George Woodring wrote:
OS: CentOS 6.6
Postgres Version: 9.3.10
I have a script that is worked for years that does the following
- Connect to postgres and get a list of URLs to poll for status
- close connection
- Start threads to poll the URLs
- cleanup threads and colle
OS: CentOS 6.6
Postgres Version: 9.3.10
I have a script that is worked for years that does the following
- Connect to postgres and get a list of URLs to poll for status
- close connection
- Start threads to poll the URLs
- cleanup threads and collect the results.
- Connect to postgres and write t
On 12/30/15 2:12 PM, Andy Colson wrote:
random_page_cost = 1
Humm, nope. I removed the config option, restart PG, then analyzed the
search table:
FYI, you can set that inside any session, any time you want. What's in
postgresql.conf is just the default value.
(For that matter, you can a
On 12/30/15 1:31 PM, Joe Conway wrote:
On 12/30/2015 11:09 AM, Cory Tucker wrote:
With this scenario you can expect an autoanalyze every 5 million rows
and autovacuum every 10 million. In my experience (and based on your
description, yours as well) this is not often enough. Not only that,
when it
*Hi,*
*I have postgresql 9.3 setup with 2 nodes (active/standby with streaming
replication & continuos archiving).*
*I have created 2 failover & failback script in order to perform a
switchover between the DB servers:*
*1. failover - create a trigger file in order to promote the new primary.*
*2. f
20 matches
Mail list logo
