Re: [GENERAL] Re: could not load library "$libdir/sslutils": in pg_upgrade process

DrakoRod writes: > Yes I installed Postgres Enterprise Manager Agent time ago in this server to > test agent, but now I don't use it. Removing the sslutils extension from the old cluster might be an easy solution, then. It sounds like someone messed up the upgrade path

[GENERAL] Performance degradation when using auto_explain

Hi, I found performance degradation when using auto_explain with log_analyze option true. It automatically logs query plan analyze results. But when there are many concurrent sessions, the performance degrades in proportion to the number of concurrent sessions. These queries are all read-only

[GENERAL] Re: could not load library "$libdir/sslutils": in pg_upgrade process

Yes I installed Postgres Enterprise Manager Agent time ago in this server to test agent, but now I don't use it. Amm if you refer the EDB install with binaries PostgreSQL one-click yes, but is not a EDB Advanced Server , is a normal Cluster installed by EDB binaries. - Dame un poco de fe,

Re: [GENERAL] What's the benefit (or usage scenario) of a "typed table"?

On 12/31/16 10:34 AM, Thomas Kellerer wrote: > I recently stumbled over "typed tables" in Postgres > (there were several questions containing this on stackoverflow recently) > > create type some_type as (id integer, data text); > create table some_table of some_type; > > I wonder what

Re: [GENERAL] could not load library "$libdir/sslutils": in pg_upgrade process

On 01/03/2017 04:39 PM, DrakoRod wrote: Hi folks! I'm try to upgrade version from 9.3.5 to 9.6.1, but in the 9.3.5 I installed the sslutils to monitoring server with a agent, but now when I want upgrade show this error pg_upgrade: From what I gather sslutils is a EDB extension for their

[GENERAL] could not load library "$libdir/sslutils": in pg_upgrade process

Hi folks! I'm try to upgrade version from 9.3.5 to 9.6.1, but in the 9.3.5 I installed the sslutils to monitoring server with a agent, but now when I want upgrade show this error pg_upgrade: /Checking for presence of required libraries fatal Your installation references

Re: [GENERAL] questions about 2nd index on one column

> Please reply to list also. apologies, my bad. > It would seem that the index would not be rebuilt, assuming all conditions are the same. Thanks for finding this. This is enough info for me to spend a day experimenting. I did not want to waste a day if we knew upfront that it wont work. But

Re: [GENERAL] questions about 2nd index on one column

On 01/03/2017 11:35 AM, Ravi Kapoor wrote: Please reply to list also. Ccing list. > Yes I am aware of django EOL. However, our company is still using it, we > have a migration plan later this year, however for now, I got to work > with what we have. Still, you are missing 14 patch releases to

Re: [GENERAL] questions about 2nd index on one column

On 01/03/2017 11:07 AM, Ravi Kapoor wrote: I have a bit strange question. I am trying to figure out how to avoid table locking while creating an index through Django (1.5.1) in Postgres 9.4.7 Django 1.5.1 does not support concurrent indexing. So my thought is to first create a concurrent index

Re: [GENERAL] questions about 2nd index on one column

On 01/03/2017 11:07 AM, Ravi Kapoor wrote: I have a bit strange question. I am trying to figure out how to avoid table locking while creating an index through Django (1.5.1) in Postgres 9.4.7 First Django 1.5.x has been past end of life for 2.25 years. Second before it went EOL it was up to

[GENERAL] questions about 2nd index on one column

I have a bit strange question. I am trying to figure out how to avoid table locking while creating an index through Django (1.5.1) in Postgres 9.4.7 Django 1.5.1 does not support concurrent indexing. So my thought is to first create a concurrent index using SQL prompt. Then try to update django

Re: [GENERAL] Error dumping 9.4: could not parse numeric array

Hi Tom, On Tue, 2017-01-03 at 09:43 -0500, Tom Lane wrote: > The only conclusion I can draw is that you have a row in pg_proc > in which proargtypes has more entries than pronargs says there > should be.  How it got that way is not apparent --- but you could > start by seeing if you can identify

Re: [GENERAL] Error dumping 9.4: could not parse numeric array

Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes: > I'm trying to take backup on my laptop, but getting an error. This is > PostgreSQL 9.4.10 on Fedora 25, installed using the community RPMS. > pg_dump -v output is: > === >

Re: [GENERAL] Error dumping 9.4: could not parse numeric array

On 01/03/2017 03:19 AM, Devrim Gündüz wrote: Hi, I'm trying to take backup on my laptop, but getting an error. This is PostgreSQL 9.4.10 on Fedora 25, installed using the community RPMS. pg_dump: could not parse numeric array "2281": too many numbers I can see this string in

Re: [GENERAL] COPY: row is too big

On Mon, Jan 2, 2017 at 2:57 PM, Rob Sargent wrote: > Perhaps this is your opportunity to correct someone else's mistake. You > need to show the table definition to convince us that it cannot be > improved. That it may be hard work really doesn't mean it's not the right >

Re: [GENERAL] Cannot recover from backup on barman

On Tue, Jan 3, 2017 at 12:20 AM, Alfredo Palhares wrote: > Well after some research, I was suggested to use the pg_resetxlog tool from > postgres-xc, but people also advise against it. I don't understand why Postgres-XC is part of this discussion as pg_resetxlog is part of

Re: [GENERAL] Error dumping 9.4: could not parse numeric array

Hi Devrim HNY On 03/01/2017 13:19, Devrim Gündüz wrote: Hi, I'm trying to take backup on my laptop, but getting an error. This is PostgreSQL 9.4.10 on Fedora 25, installed using the community RPMS. pg_dump: could not parse numeric array "2281": too many numbers I can see this string in

[GENERAL] Error dumping 9.4: could not parse numeric array

Hi, I'm trying to take backup on my laptop, but getting an error. This is PostgreSQL 9.4.10 on Fedora 25, installed using the community RPMS. pg_dump: could not parse numeric array "2281": too many numbers   I can see this string in src/bin/pg_dump/common.c, but no idea why this happens. gdb