2013/1/29 Adrian Klaver
>
>> Are they never tracked or just sometimes?
> Is it particular functions or random?
>
>
> and this is strange for me.
I have few DBs with the same function (copy -> paste), in one DB they are
tracked (visible in pg_stat_user_functions) in other not. In DB where some
fun
Hello Kevin,
On Wed, Jan 30, 2013 at 12:09 AM, Kevin Grittner wrote:
> Alexander Farber wrote:
>
>> update pref_users set medals = 0;
>> UPDATE 223456
>
> You're probably going to like your performance a lot better if you
> modify that to:
>
> update pref_users set medals = 0 where medals <> 0;
Hello!
I update the databases to version 9.1.
Today, faced with a new challenge.
The database itself is not very big 60G, but has ~ 164,000 tables in 1260
schemes.
I tried and pg_upgrade and pg_dumpall and pg_dump.
But they all work very, very long time.
For so long that I do not have patience.
A
>> drop role tim;
>> ERROR: role "tim" cannot be dropped because some objects depend on it
>> DETAIL: owner of default privileges on new relations belonging to
>> role tim in schema strongmail
>
> DROP OWNED BY ought to get rid of that.
Just to be clear.
I don't want to drop the schema. Will D
Tim Uckun writes:
> I am unable to drop a user.
> drop role tim;
> ERROR: role "tim" cannot be dropped because some objects depend on it
> DETAIL: owner of default privileges on new relations belonging to
> role tim in schema strongmail
DROP OWNED BY ought to get rid of that.
> ALTER DEFAULT P
I am unable to drop a user.
drop role tim;
ERROR: role "tim" cannot be dropped because some objects depend on it
DETAIL: owner of default privileges on new relations belonging to
role tim in schema strongmail
ALTER DEFAULT PRIVILEGES IN SCHEMA strongmail
REVOKE INSERT, SELECT, UPDATE, DELET
Alexander Farber wrote:
> update pref_users set medals = 0;
> UPDATE 223456
You're probably going to like your performance a lot better if you
modify that to:
update pref_users set medals = 0 where medals <> 0;
-Kevin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
On 01/29/2013 05:03 AM, DANIEL CRISTIAN CRUZ wrote:
Hello,
I build a function and added some warnings where the id of the affected
rows are inside it; and would be nice to put it into a detail, not in
the message, since pgbadger can group it and I can see clearly what is
wrong in my cluster.
I
Hello,
I build a function and added some warnings where the id of the affected
rows are inside it; and would be nice to put it into a detail, not in
the message, since pgbadger can group it and I can see clearly what is
wrong in my cluster.
I read the manual and tried something with no success:
Chris Angelico writes:
> On Wed, Jan 30, 2013 at 2:16 AM, Tom Lane wrote:
>> It's hard to muster much excitement about that when we've already
>> got "numeric".
> True, but I wasn't able (with 9.1, so that might have changed since)
> to add inet to numeric. Maybe that would be easier?
There's n
On 01/29/2013 07:36 AM, Bartosz Dmytrak wrote:
2013/1/29 Adrian Klaver mailto:adrian.kla...@gmail.com>>
Not quite sure what you are asking.
I am asking for info why not all functions are tracked.
"All" - I mean plpgsql functions. Just like I said before, I am aware
not all functions all
2013/1/29 Adrian Klaver
>
> Not quite sure what you are asking.
I am asking for info why not all functions are tracked.
"All" - I mean plpgsql functions. Just like I said before, I am aware not
all functions all tracked but my functions (written in plpgsql) should be.
Regards,
Bartek
On 01/29/2013 03:50 AM, Bartosz Dmytrak wrote:
Hi all,
Does anyone have an idea why it works like this?
Not quite sure what you are asking. On the assumption that functions are
not showing up in the view, have you checked:
http://www.postgresql.org/docs/9.2/static/runtime-config-statistics.h
On Wed, Jan 30, 2013 at 2:16 AM, Tom Lane wrote:
> Chris Angelico writes:
>> Or alternatively, does PostgreSQL have any integer type larger than
>> 64-bit bigint? I've become accustomed to using bignums in most of my
>> programming; arbitrary-precision integers allow all sorts of handy
>> flexibi
On 01/28/2013 09:24 PM, Hari Babu wrote:
> While testing PostgreSQL JDBC java client to connect to the PG 9.2.1
> database server using SSL.
> we got the following behavior.
>
> The test steps as below：
>
> url = "jdbc:postgresql://" + "10.145.98.227" + ':'
> + "8707" + '/'
>
Chris Angelico writes:
> Or alternatively, does PostgreSQL have any integer type larger than
> 64-bit bigint? I've become accustomed to using bignums in most of my
> programming; arbitrary-precision integers allow all sorts of handy
> flexibilities. Are there any plans to add bignums (something li
On Tue, Jan 29, 2013 at 9:34 PM, George Shuklin
wrote:
> But IPv6 is differ. Let's assume we wants to get 'next' /64 range. Current
> range is inet'2a00:ab00:0:1/64'. We want next.
>
> Postgres do not allow adding inet + inet, so we need to add natural number.
> But 'next' /64 is 'just' 2^64. And
Hi all,
Does anyone have an idea why it works like this?
Regards,
Bartek
Good day.
We trying to implement IPv6 address space management with postgres
support, but I found few strange problems.
One of them - problems with math. In IPv4 we can be sure, that
inet'0.0.0.1' + N allows to get any address you want, because N < 2^64,
and IPv4 is just 32-bit size.
But I
19 matches
Mail list logo
