Josh Loberant writes:
> Was this issue ever resolved?
> We are now having Nagios checks failing due to the pg_size_pretty function,
> and the check runs fine on my local machine 9.1 (fails on 9.2 and 9.3, both
> having two pg_size_pretty functions).
Nothing was done about it so far for lack of co
Was this issue ever resolved?
We are now having Nagios checks failing due to the pg_size_pretty function,
and the check runs fine on my local machine 9.1 (fails on 9.2 and 9.3, both
having two pg_size_pretty functions).
Thanks,
Josh
--
View this message in context:
http://postgresql.1045698.n5
On Wed, Oct 10, 2012 at 11:49:50AM -0700, Josh Berkus wrote:
>
> >> Assuming that's how 9.2 ships, we might as well wait to see if there
> >> are any real complaints from the field before we decide whether any
> >> changing is needed.
>
> So, here's a complaint: 9.2 is breaking our code for check
On 21 October 2012 16:59, Kevin Grittner wrote:
> I don't know about anyone else, but I could live with that.
Me too.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Robert Haas wrote:
> You know, if we implemented what Tom proposed here:
>
> http://archives.postgresql.org/pgsql-hackers/2012-08/msg01055.php
>
> ...then we probably get away with removing pg_size_pretty(bigint)
> and then this would Just Work. pg_size_pretty(numeric) is doubtless
> a little sl
On Wed, Oct 10, 2012 at 2:49 PM, Josh Berkus wrote:
> So, here's a complaint: 9.2 is breaking our code for checking table sizes:
>
> postgres=# select pg_size_pretty(100);
> ERROR: function pg_size_pretty(integer) is not unique at character 8
You know, if we implemented what Tom proposed here:
>> Assuming that's how 9.2 ships, we might as well wait to see if there
>> are any real complaints from the field before we decide whether any
>> changing is needed.
So, here's a complaint: 9.2 is breaking our code for checking table sizes:
postgres=# select pg_size_pretty(100);
ERROR: function
On Tue, Jun 5, 2012 at 8:01 AM, Tom Lane wrote:
> Jim Nasby writes:
>> On 5/27/12 2:54 PM, Euler Taveira wrote:
>>> On 27-05-2012 10:45, Fujii Masao wrote:
OK, let me propose another approach: add pg_size_pretty(int).
>
>>> I wouldn't like to add another function but if it solves both proble
Magnus Hagander writes:
> On Tue, Jun 5, 2012 at 1:01 AM, Tom Lane wrote:
>> Assuming that's how 9.2 ships, we might as well wait to see if there
>> are any real complaints from the field before we decide whether any
>> changing is needed.
> We could add it to the catalog without forcing an init
On Tue, Jun 5, 2012 at 1:01 AM, Tom Lane wrote:
> Jim Nasby writes:
>> On 5/27/12 2:54 PM, Euler Taveira wrote:
>>> On 27-05-2012 10:45, Fujii Masao wrote:
OK, let me propose another approach: add pg_size_pretty(int).
>
>>> I wouldn't like to add another function but if it solves both proble
Jim Nasby writes:
> On 5/27/12 2:54 PM, Euler Taveira wrote:
>> On 27-05-2012 10:45, Fujii Masao wrote:
>>> OK, let me propose another approach: add pg_size_pretty(int).
>> I wouldn't like to add another function but if it solves both problems... +1.
> FWIW, I would argue that the case of pg_siz
On 5/27/12 2:54 PM, Euler Taveira wrote:
On 27-05-2012 10:45, Fujii Masao wrote:
OK, let me propose another approach: add pg_size_pretty(int).
If we do this, all usability and performance problems will be solved.
I wouldn't like to add another function but if it solves both problems... +1.
F
> Euler Taveira wrote:
> On 27-05-2012 10:45, Fujii Masao wrote:
>> OK, let me propose another approach: add pg_size_pretty(int).
>> If we do this, all usability and performance problems will be
>> solved.
>
> I wouldn't like to add another function but if it solves both
> problems... +1.
It fix
On 27-05-2012 10:45, Fujii Masao wrote:
> OK, let me propose another approach: add pg_size_pretty(int).
> If we do this, all usability and performance problems will be solved.
>
I wouldn't like to add another function but if it solves both problems... +1.
--
Euler Taveira de Oliveira - Timbir
On Sun, May 27, 2012 at 1:33 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Sat, May 26, 2012 at 9:30 AM, Tom Lane wrote:
>>> The argument for adding pg_size_pretty(numeric) was pretty darn thin in
>>> the first place, IMHO; it does not seem to me that it justified this
>>> loss of usability.
>
Fujii Masao writes:
> On Sat, May 26, 2012 at 9:30 AM, Tom Lane wrote:
>> The argument for adding pg_size_pretty(numeric) was pretty darn thin in
>> the first place, IMHO; it does not seem to me that it justified this
>> loss of usability.
> Ouch! But removing pg_size_pretty(numeric) causes anot
On 26-05-2012 01:45, Fujii Masao wrote:
> Ouch! But removing pg_size_pretty(numeric) causes another usability
> issue, e.g., pg_size_pretty(pg_xlog_location_diff(...)) fails. So how about
> removing pg_size_pretty(bigint) to resolve those two issues?
> I guess pg_size_pretty(numeric) is a bit slowe
On Sat, May 26, 2012 at 9:30 AM, Tom Lane wrote:
> In 9.1:
>
> regression=# select pg_size_pretty(8*1024*1024);
> pg_size_pretty
>
> 8192 kB
> (1 row)
>
> In HEAD:
>
> regression=# select pg_size_pretty(8*1024*1024);
> ERROR: function pg_size_pretty(integer) is not unique
> LIN
In 9.1:
regression=# select pg_size_pretty(8*1024*1024);
pg_size_pretty
8192 kB
(1 row)
In HEAD:
regression=# select pg_size_pretty(8*1024*1024);
ERROR: function pg_size_pretty(integer) is not unique
LINE 1: select pg_size_pretty(8*1024*1024);
^
HINT: Could n
19 matches
Mail list logo
