Just wanted to report that I rolled back my VM to where it was with 9.4.2
installed and it wouldn't start. I installed 9.4.4 and now it starts up
just fine:
> 2015-06-12 16:05:58 PDT [6453]: [1-1] LOG: database system was shut down
at 2015-05-27 13:12:55 PDT
> 2015-06-12 16:05:58 PDT [6453]: [2-1
Please do not remove the mailing list from replies. See below.
On Fri, 12 Jun 2015 09:21:19 -0300
Anderson Valadares wrote:
> 2015-06-08 20:33 GMT-03:00 Bill Moran :
>
> > On Mon, 8 Jun 2015 11:59:31 -0300
> > Anderson Valadares wrote:
> >
> > > Hi
> > > We are experiencing an intermittent p
On Fri, Jun 12, 2015 at 09:37:36PM +, Sheena, Prabhjot wrote:
> Here is some more information
>
> pool_mode | transaction
>
> We have transactional pooling and our application is set up in such a way
> that we have one query per transaction. We have set default pool size to
Please do not cross-post on the PostgreSQL lists. Pick the most
appropriate list to post to and just post there.
cheers
andrew
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Here is some more information
pool_mode | transaction
We have transactional pooling and our application is set up in such a way that
we have one query per transaction. We have set default pool size to 100.
This is output . As you guys can see active connection are 100 and 224 a
Unsubscribe
On Fri, Jun 12, 2015 at 8:57 PM, Sheena, Prabhjot <
prabhjot.si...@classmates.com> wrote:
> Guys we see spike in pg bouncer during the peak hours and that was
> slowing down the application. We did bump up the connection limit and it is
> helpful but now we again notice little spike
Francisco Olarte wrote
> Hi Greg:
>
> On Fri, Jun 12, 2015 at 4:08 PM, greg <
> gregory.jevardat@
> > wrote:
>> I cannot find any documentation on the space taken by a double precision
>> array. And the few tests I did surprise me.
>>
>> Here are a few tries I did to understand
>> select pg_colu
I was recently surprised by changes that were not logged by
log_statement = 'mod'. After changing log_statement to 'all', I found
that the changes were occurring in a writable CTE.
Is there a way to log all statements that update data?
Jack
--
Sent via pgsql-general mailing list (pgsql-gene
Guys we see spike in pg bouncer during the peak hours and that was slowing down
the application. We did bump up the connection limit and it is helpful but now
we again notice little spike in connection. And one thing that I notice that
is different is jump in sv_used value when I run command sh
Hi Greg:
On Fri, Jun 12, 2015 at 4:08 PM, greg wrote:
> I cannot find any documentation on the space taken by a double precision
> array. And the few tests I did surprise me.
>
> Here are a few tries I did to understand
> select pg_column_size(1.1::double precision) return 8--- a
>
>
>> I wrote that type off as something I would never code into my own
>> schema so basically forgot about its usability in other situations.
>>
>
> Though if you do not want to use the money type in a table you could do:
>
> test=> select '$18,665'::money::numeric;
> numeric
> --
> 18
On 06/12/2015 10:11 AM, David G. Johnston wrote:
On Fri, Jun 12, 2015 at 12:57 PM, Adrian Klaver
mailto:adrian.kla...@aklaver.com>>wrote:
On 06/12/2015 09:46 AM, David G. Johnston wrote:
Version 9.3
CREATE TABLE t ( field numeric NULL );
SELECT * FROM json_populate_r
On Fri, Jun 12, 2015 at 12:57 PM, Adrian Klaver
wrote:
> On 06/12/2015 09:46 AM, David G. Johnston wrote:
>
>> Version 9.3
>> CREATE TABLE t ( field numeric NULL );
>> SELECT * FROM json_populate_record(null::t, '{ "field": "$18,665"
>> }'::json);
>> Error: invalid input syntax for type numeric:
On 06/12/2015 09:46 AM, David G. Johnston wrote:
Version 9.3
CREATE TABLE t ( field numeric NULL );
SELECT * FROM json_populate_record(null::t, '{ "field": "$18,665" }'::json);
Error: invalid input syntax for type numeric: "$18,665"
I can accept the type of field being something like "numeric_cl
Version 9.3
CREATE TABLE t ( field numeric NULL );
SELECT * FROM json_populate_record(null::t, '{ "field": "$18,665" }'::json);
Error: invalid input syntax for type numeric: "$18,665"
I can accept the type of field being something like "numeric_cleaned" which
has a custom input function that would
On 06/12/2015 09:24 AM, Manuel Kniep wrote:
using a row type variable in a trigger function results in an error
after changing the table structure
running the following sequence of statements
(https://gist.github.com/rapimo/accac676f7c8e3557a4d)
CREATE TABLE foo(
id integer
);
CREATE FUNCTI
Hello all,
I am playing with multiple nodes to understand how cleanly to detach a
node. Even after reading the post
"[BDR] Node Join Question"
(http://www.postgresql.org/message-id/flat/canf8rlvyxslpxohucsvdbcvnktmnihkkmy2_ncer3egky+a...@mail.gmail.com#canf8rlvyxslpxohucsvdbcvnktmnihkkmy2_nc
Exactly, that’s why there’s a limit on the retry number. On the last try I
wanted something like full lockdown to make sure the transaction will not fail
due to serialiazation failure (if no other processes are touching the database,
it can’t happen).
So if two transactions were retrying over a
using a row type variable in a trigger function results in an error after
changing the table structure
running the following sequence of statements
(https://gist.github.com/rapimo/accac676f7c8e3557a4d)
CREATE TABLE foo(
id integer
);
CREATE FUNCTION foo_trigger() RETURNS trigger LANGUAGE plp
Melvin Davidson wrote on Friday, June 12, 2015 5:10 PM:
> To allow external ip access, you need to specifcally add the ip's to the
> pg_hba.conf on the PostgreSQL server
> and then reload the PostgreSQL cluster. IE: pg_ctl reload
Generally, yes. But the original poster’s error message said “No
You also did not state which O/S you are working with or which version of
PostgreSQL you are using.
In either case, you still need to update the pg_hba.conf file and then
reload.
http://www.postgresql.org/docs/9.1/static/auth-pg-hba-conf.html
On Fri, Jun 12, 2015 at 11:32 AM, Mephysto wrote:
>
I am sorry, I forgot to say that port of my database in postgresql.conf is
setted to 5997.
Byem
Meph
On 12 June 2015 at 17:10, Melvin Davidson wrote:
> The default port for PostgreSQL is 5432.
> To allow external ip access, you need to specifcally add the ip's to the
> pg_hba.conf on the Post
The default port for PostgreSQL is 5432.
To allow external ip access, you need to specifcally add the ip's to the
pg_hba.conf on the PostgreSQL server
and then reload the PostgreSQL cluster. IE: pg_ctl reload
On Fri, Jun 12, 2015 at 10:58 AM, mephysto wrote:
> Hi there,
> I am trying to install
Hi there,
I am trying to install a postgres cluster in a XenSever VM: I did not have
any difficulties in compiling, installing and starting the DB. The problem
is that I can not access to this db from an external machine: I tried to
configure port forwarding through iptables as well as I did for ss
greg writes:
> I cannot find any documentation on the space taken by a double precision
> array. And the few tests I did surprise me.
> Here are a few tries I did to understand
> select pg_column_size(1.1::double precision) return 8--- as
> expected
> select pg_column_size('{}':
Hi all
I cannot find any documentation on the space taken by a double precision
array. And the few tests I did surprise me.
Here are a few tries I did to understand
select pg_column_size(1.1::double precision) return 8--- as
expected
select pg_column_size('{}'::double precision[
Thanks David for the nice suggestion.
Text search would not my requirement. Because user wants to provide condition
similar to where clause.
I thought let postgres query the data based on only time column. That result
would be stored in cursor and fetch 5000 sequentially when the user ask. Onc
Michael Shapiro writes:
> Thanks for this response. It still leave my question unanswered. I should
> rephrase it -- will become a native datatype in Postgres (as
> opposed to remaining an extension). Are there any plans to make a
> native datatype?
No. That is not the same as it being unsuppo
On Thu, Jun 11, 2015 at 12:57 PM Tom Lane wrote:
> alter table t alter u type uuid[] using u::uuid[];
>
> The original command worked without a USING because anything-to-text is
> considered an allowable assignment coercion; but the other way around
> requires an explicit cast.
Got it. Thanks!
I
On Friday, June 12, 2015, Michael Shapiro wrote:
>
> The reason I am asking is that, although ltree seems to have been a
> contributed module since at least 8.3, how can one know if it will always
> be part of subsequent versions of Postgres?
>
Whether contrib, core, or an external extension you
On Friday, June 12, 2015, Michael Shapiro wrote:
> Hi Melvin,
>
> Thanks for this response. It still leave my question unanswered. I should
> rephrase it -- will become a native datatype in Postgres (as
> opposed to remaining an extension). Are there any plans to make a
> native datatype?
>
In
Hi Melvin,
Thanks for this response. It still leave my question unanswered. I should
rephrase it -- will become a native datatype in Postgres (as
opposed to remaining an extension). Are there any plans to make a
native datatype?
Michael
On Fri, Jun 12, 2015 at 7:58 AM, Melvin Davidson
wrote:
Geometric Data Types have been in PostgreSQL for quite a while.
http://www.postgresql.org/docs/9.2/interactive/datatype-geometric.html
JSON have been in PostgreSQL since 9.2 and it's functionality increases
with each new version.
http://www.postgresql.org/docs/9.2/interactive/datatype-json.html
A
I am wondering if the contributed module will always be part of
Postgres? Do contributed modules ever get absorbed into Postgres itself?
The reason I am asking is that, although ltree seems to have been a
contributed module since at least 8.3, how can one know if it will always
be part of subsequ
On Jun 12, 2015 1:33 PM, "Albe Laurenz" wrote:
>
> Birta Levente wrote:
> > In the postgresql yum repo appeared the 9.3.9 and 9.4.4, but on the
> > postgresql.org nothing about the new version. Where I can see the
changelog?
>
> AFAIK, it is being packaged and will be announced soon.
The rpm pack
Birta Levente wrote:
> In the postgresql yum repo appeared the 9.3.9 and 9.4.4, but on the
> postgresql.org nothing about the new version. Where I can see the changelog?
AFAIK, it is being packaged and will be announced soon.
Yours,
Laurenz Albe
--
Sent via pgsql-general mailing list (pgsql-gen
Hi all
In the postgresql yum repo appeared the 9.3.9 and 9.4.4, but on the
postgresql.org nothing about the new version. Where I can see the changelog?
Thanks
--
Levi
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
37 matches
Mail list logo
