[GENERAL] how to decrease the promotion time when performing a multiple failovers.....

*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.

Re: [GENERAL] cannot get stable function to use index

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

[GENERAL] SSL connection issue via perl

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

Re: [GENERAL] Efficiently Triggering Autovacuum Analyze?

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

Re: [GENERAL] to_timestamp alternatives

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

Re: [GENERAL] to_timestamp alternatives

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

Re: [GENERAL] SSL connection issue via perl

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

Re: [GENERAL] SSL connection issue via perl

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: > >>

Re: [GENERAL] to_timestamp alternatives

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

[GENERAL] Happy New Year

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

Re: [GENERAL] to_timestamp alternatives

...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

Re: [GENERAL] SSL connection issue via perl

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

Re: [GENERAL] to_timestamp alternatives

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

Re: [GENERAL] to_timestamp alternatives

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

[GENERAL] to_timestamp alternatives

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

Re: [GENERAL] to_timestamp alternatives

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

Re: [GENERAL] to_timestamp alternatives

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

Re: [GENERAL] to_timestamp alternatives

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'||'

Re: [GENERAL] to_timestamp alternatives

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

Re: [GENERAL] Happy New Year

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: