Re: [GENERAL] GIN Trigram Index Size

2015-09-14 Thread Christian Ramseyer
On 10/09/15 06:40, Jeff Janes wrote: > Vacuuming will allow the space to be reused internally. It will not > visibly shrink the index, but will mark that space as eligible for reuse. > > If you have a 36GB index and a reindex would have reduced it to 15GB, > then a vacuum will leave it at 36GB

Re: [GENERAL] Ubuntu installed postgresql password failure

2015-09-14 Thread Jan de Visser
On September 14, 2015 07:22:58 AM Martín Marqués wrote: > I would recommend using psql's \password meta- command instead of ALTER > USER to change a password, as to avoid having the password stamped in > the logs. You learn something new every day :-) jan

Re: [GENERAL] GIN Trigram Index Size

2015-09-14 Thread Francisco Olarte
Hi Christian: On Mon, Sep 14, 2015 at 1:54 PM, Christian Ramseyer wrote: > I agree with your append-only and disposable partition approach, it > would work a lot better. The idea with using a second schema for > selective backups is great, I'll totally steal this :) Feel free.

[GENERAL] issue, dumping and restoring tables with table inheritance can alter column order

2015-09-14 Thread Ingmar Brouns
Hi, Im running: PostgreSQL 9.4.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6), 64-bit I make use of table inheritance. I've created a table, added a child table, and after that added a column to the parent table (example code below). As you can see below

Re: [GENERAL] issue, dumping and restoring tables with table inheritance can alter column order

2015-09-14 Thread David G. Johnston
On Mon, Sep 14, 2015 at 11:11 AM, Ingmar Brouns wrote: > > However, when I dump the schema using pg_dump, and then load the > resulting sql file, suddenly 'c' does follow 'a'. So restoring my > schema has changed my table's layout. I feel dumping and loading > should not alter

Re: [GENERAL] Ubuntu installed postgresql password failure

2015-09-14 Thread Jan de Visser
On September 14, 2015 07:22:58 AM Martín Marqués wrote: > I would recommend using psql's \password meta- command instead of ALTER > USER to change a password, as to avoid having the password stamped in > the logs. You learn something new every day :-) jan

Re: [GENERAL] issue, dumping and restoring tables with table inheritance can alter column order

2015-09-14 Thread Jim Nasby
On 9/14/15 11:59 AM, David G. Johnston wrote: On Mon, Sep 14, 2015 at 11:11 AM, Ingmar Brouns >wrote: However, when I dump the schema using pg_dump, and then load the resulting sql file, suddenly 'c' does follow 'a'. So restoring my schema

Re: [GENERAL] BDR problem

2015-09-14 Thread Martín Marqués
El 14/09/15 a las 06:37, Craig Ringer escribió: > > Support is focused mainly on RHEL/CentOS/Fedora, but Debian/Ubuntu > packages are also produced. We're a little behind at the moment and > haven't got 0.9.2 packages out. I'll be pushing 0.9.3 soon and will > produce 0.9.3 packages for

Re: [GENERAL] clone_schema function

2015-09-14 Thread Jim Nasby
On 9/12/15 9:38 AM, Daniel Verite wrote: "seriously flawed" is a bit of a stretch. Most sane developers would not >have schema names of one letter. >They usually name a schema something practical, which totally avoids your >nit picky exception. That's confusing the example with the problem it

Re: [GENERAL] clone_schema function

2015-09-14 Thread Melvin Davidson
Jim, Have you actually tried this, or is it just a theory? AFAIK, the function will work because only the schema name is changed.. So please provide a full working example of a function that fails and I will attempt a solution. On Mon, Sep 14, 2015 at 6:36 PM, Jim Nasby

Re: [GENERAL] clone_schema function

2015-09-14 Thread Melvin Davidson
Actually, on further thought, you example shows that it works correctly because we do want all references to the old schema to be changed to the new schema, since all copies of functions will now reside in the new schema. Otherwise, there is no point of duplicating those functions. On Mon, Sep

[GENERAL] pgpass (in)flexibility

2015-09-14 Thread Ben Chobot
We're in a situation where we would like to take advantage of the pgpass hostname field to determine which password gets used. For example: psql -h prod-server -d foo # should use the prod password psql -h beta-server -d foo # should use the beta password This would *seem* to be simple, just

Re: [GENERAL] BDR problem

2015-09-14 Thread Giovanni Maruzzelli
http://bdr-project.org/docs/next/index.html On Fri, Sep 11, 2015 at 11:21 PM, Charles Lynch < charleslynchpostgre...@gmail.com> wrote: > So for about a month now, we've been getting things prepared to use a BDR > cluster in a production, multi-region setup on aws. Our initial testing > produced

Re: [GENERAL] [BUGS] BUG #13619: regression functions return Null

2015-09-14 Thread David G. Johnston
Oh, and don't reply to people individually. I'm going to move this to -general with one last copy for -bugs even though it is not one. On Mon, Sep 14, 2015 at 3:01 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Mon, Sep 14, 2015 at 2:55 PM, Biswadeep Banerjee < >

Re: [GENERAL] BDR problem

2015-09-14 Thread Craig Ringer
On 12 September 2015 at 05:21, Charles Lynch wrote: > We have, just recently, ran into a problem. I created a test cluster only > within NV and after about a week of working without any problems, we got an > error: Unexpected EOF on SSL connection. I had seen

Re: [GENERAL] Ubuntu installed postgresql password failure

2015-09-14 Thread Martín Marqués
El 13/09/15 a las 18:20, Jan de Visser escribió: > > Try > > jan@bison:~$ sudo -u postgres -s > postgres@bison:~$ psql > psql (9.4.4) > Type "help" for help. > > postgres=# ALTER USER postgres PASSWORD 'postgres'; > ALTER ROLE > postgres=# \q I would recommend using psql's \password